2009년 4월 15일 수요일
케텔과 AOL이 사라진 이유를 모르는... 이동통신사들...
분명... '공룡'이라 불릴만한...
그들이 시대를 주름잡던 시대가 있었다.
'컴퓨서브'로 천하를 주름잡고...
'케텔'로 통신시장을 주름잡던...
그런 시대가 있었다.
하지만...
'참여'를 중심으로한 인터넷 환경에...
'컴퓨터브', 'AOL'이 몰락하고...
국내의 상황도 '케텔(하이텔)', '천리안'도 마찬가지로...
그 시대와 함께 운명을 같이 한것이다.
그런데...
당시 '하이텔'이 몰락한 이유는 아주 간단했다.
사용자들로부터 받는 Telnet관련 통신비용 1인당 7천원~3천원의 '사용료'에 대한
유혹에서 벗어나지 못했기 때문이다.
그런데...
이제는 '참여'의 시대를 지나..
'오픈마켓'의 시대가 도래했고.
iPhone이나 안드로이드는...
절대 다수의 개발자들에 이익을 돌려주는
'오픈마켓'환경으로 시대가 변하고 있다.
이제는 '컨텐츠'의 '이익'에 빠져든
국내의 이통통신사들 또한...
그러한 '공룡'의 시대를 맞이하게 될것인가?
그나마..
비슷하게 흉내는 내고 있습니다.
LG 개발자 네트워크 ( http://developer.lgmobile.com )
삼성 모바일 이노베이터 ( http://innovator.samsungmobile.com )
하지만...
NDA조항까지..
독소조항 까지 없는
iPhone ( http://devloper.apple.com/iphone )
자...
과연 '개발자'들의 마음을 얻고..
그 '개발자'들과 공존할 마음이 있는 곳은 어디일까요?
과거 '참여'의 시대에...
그 '참여'에 같이 공조하지 못한 회사들은 이미 이 시대에서 보이지도 않습니다.
이제 '참여'와 '오픈마켓'의 시대에서...
과연 국내 개발사나 이동통신사들은 어떠한 정책으로써
'개발자'들과 호흡할까요?
마치...
iPhone만을 막으려고 애쓰는 모습은...
과거 쇄국정책을 사용하던 그런 모습을 보이는 것 아닐까요?
현재와 똑같은 정책을 계속 고수한다면...
국내의 이통통신사들과
휴대폰을 만드는 회사들의 운명도...
결국은...
과거의 '공룡'이 되지 않을까 합니다.
2009년 4월 7일 화요일
오픈소스 개발이 성공하려면...
많은 개발자들이 오픈소스 기반의 지식에 도움을 받고 있고...
그러한 오픈소스 프로젝트에 참여하고픈 욕심은 생기지만...
뚜렷한 방향성없이...
찻잔속의 태풍이거나...
머릿속에 맴돌다 끝나는 경우가 많다.
특히나...
우리나라 개발자들의 경우에는 더더욱 힘이 든다.
수많은 오픈소스개발과
엄청난 지적 재산이 공개된...
http://sourceforge.net/
그 영역의 방대함과...
그 동안 문을 닫은 컴포넌트 회사들의 소스까지 오픈되어 있는...
정말 진정한 의미의 오픈 소스 공간인듯 하다.
개발경력이 좀 되고...
이름이 좀 알려진 사람들의 경우에는...
누구나 한번쯤 자신이 오픈소스를 시작해서 운영해보면 어떨까하는 욕심이 생긴다.
그러한 마음을 가졌다가도...
많은 현실속에서 그 꿈을 닫아버리는 경우가 허다하다.
그렇다면...
오픈소스 개발에 성공하려면 어떻게 해야할까?
그것도...
꼭... 소스포지가 아니라..
우리나라의 까페나 인터넷 환경에서?
1. 정말 흥미있는 소재여야 한다.
누구나 다 만들어 본듯한 것들... 비슷 비슷한 소재가 아니라.
아주 색다른 소재여서..
그 소재에 호감을 가지는 사람들이 한둘 이상 모여야만
그 프로젝트는 꾸준하게 진행할 수 있다.
2. 가능하면 '언어'영역부터 공략하라.
PHP와 Ruby와 같은 언어들은 그냥 탄생한 것들이 아니다.
한 사람의 창조자가 끊임없는 자신의 개량과 달굼질 속에서 완성된 것이다.
우리나라 최초의 '언어'를 오픈소스 형태로 진행할 멋진 사람은 언제쯤 나타날까?
3. 일단 '영어'는 잘해야 한다. ~.~
좁디 좁은 국내 개발자들과 협업하는 것은 정말 힘이 듭니다.
왜냐구요? 사회 여건상 소프트웨어 개발자들이 여유롭게 오픈소스에 참여하는 사회적인 기반이 되어 있지 않기 때문에... 외국계 개발자들과 협업해야 하는데... 그 의사소통의 가장 기본은 '영어'이기 때문이죠.
4. 최소 1년 이상 자신이 환경을 만들어야 한다.
누가 시켜서가 아니라...
내가 좋아서 하는 일이어야 합니다.
Linux와 같은 거대한 플랫폼도...
자그마한 커널을 만들면서 시작했습니다.
~.~
자그마한 것 부터 알차게 준비하다보면...
언젠가는 그 결과를 볼 수 있지 않을까요?
5. 욕심을 버려라..
다시 한번 생각해보세요?
오픈프로젝트를 진행하면서 얻고 싶은 것이 무엇인지?
'명성'?
만일 '명성'을 원하신다면...
오픈 소스프로젝트를 진행하는 것을 말리고 싶습니다.
차라리...
그 정도 공을 커뮤니티나 '책'을 쓰는데 몰두 하시는 것이
훨씬 성과도 좋답니다.
오픈 소스 프로젝트를 통해서 명성을 얻은 분들을 살펴보면...
자연스럽게 얻게 되는 것이지.
그 분들 자체가 '명성'을 목적으로 시작한일은 아니라는 것이죠...
~.~
마지막으로...
오픈소스프로젝트를 꼭..
내가 만들 필요있겠습니까?
http://sourceforge.net/
소소포지에 가보세요...
정말 많은 프로젝트들이 진행되고 있답니다.
그 공간에 같이 어울릴 수 있는 곳을 찾는 것도
의미가 크답니다.
꼭 내가 아니더라도...
같이 어울릴 수 있는 그런 멤버들을 만나는 경험...
한번 느끼고 싶지 않으신가요?
~.~
2009년 3월 24일 화요일
IE8의 의미는... 악몽의 IE6은 잘못되었다고 시인하는 것뿐...
웹쪽의 프로그래밍이나 작업을 하는 사람들에게 가장 큰 난관이 하나 있다.
그것은...
넘을 수 없는 커다란 태백산맥!
바로...
IE6...
Explorer 6 버전이다.
가장 비표준으로 만들어진 이 IE6의 환경은 정말로 극악의 브라우져였다.
소위...
크로스 환경을 만든다고 만들어 보면...
유일하게 반항하는 넘이~~~
바로 이 IE6이다.
IE6은 2001년 8월에 정식으로 릴리즈되고 5년동안 세상을 지배(?)하다가...
2006년 10월쯤에 출시된 FireFox에 긴장하며...
2006년 11월 바로 IE7을 출시하게 됩니다.
그런데 잠 재미있는 것은 2001년부터 그후 시대는...
윈도우즈 XP의 전성시대로써...
거의 대부분의 사용자들은 IE6이 당연한 지배적 브라우져이기 때문에...
이 사실상의 표준인 브라우져에 맞추어서 작업을 하게되고...
그 시대에 가장 많은 홈페이지(?)를 구축한 대한민국의 환경은...
IE 표준 정도가 아니라...
거의
IE6 표준으로 환경을 구축했다는 점이 문제입니다.
머... 이제 IE7, IE8을 만들어도...
IE6의 환경을 지원해야하는지 말아야 하는지도 고민거리이니...
ㅋㅋ
전세계에 퍼져있는 Windows XP를 모두 수거하기 전에는...
해결이 안될 문제죠.
좌우당간...
MS도 IE6의 실수를 진즉에 인정하고 진즉에 IE7을 발표했으면 좋으련만...
아마도...
자신들의 브라우져간의 싸움이 IE6과 IE8과의 싸움이 될터인데...
사실상...
브라우져의 보급률을 비교해보면...
현재 점유율에서는 사실상 FireFox가 대세라고 해도 과언이 아닙니다.
그 이유는...
여기서 단순하게 그림만 놓고 본다면... IE가 67%, FireFox가 21%로 나옵니다.
이 그림을 버전별로 살펴보면...
IE7은 47.32%, IE6은 18.85%
FireFox 3.0은 19.11%, FireFox 2.0은 2.27%로써...
IE 점유율은 시간이 지날 수록 IE7은 거의 현상을 유지한체로...
IE6의 시장만 줄어들고 있습니다.
그 자리를 FireFox가 차지하고 있다고 봐야겠죠?
이번에 IE8은 이러한 IE6이 줄어드는 자리를 메우기 위한 하나의 수단으로 보이는데...
과연 시장의 선택은 어떤식으로 결론이 날까요?
정말 흥미진진한 전개가 아닐 수 없습니다.
~.~
2009년 3월 21일 토요일
브라우져들의 재격돌... 꿈꾸는자가 끄적거려본 UI설계 철학들...
어제 전세계적으로 IE8 버전이 정식 출시되었다는 소식에...
문득, 제 PC를 살펴보니.
와우~~ 브라우져 3종을 다 쓰고 있었네요...
( 사실.. 이렇게 다 쓰는 이유중에 하나가 IE7의 대책없는 뻗음 때문이라는 사실도... )
Google 크롬은 1.0.154.48 버전...
Safari는 4 Public Beta(528.16)...
그리고, IE는 좀전에 업그레이드 해서
Ie 8.0.6001.18702
재미있는 것은 브라우져들이 각자 비슷하면서도...
또 다른 모습들...
가장 최근.. ( 머.. 어제 나왔으니.. ) IE8을 살펴볼까요?
탭에 배치된 무수한 기능들... 역시.. MS는 기능하나로 뭉치기는 참 잘한다는...
역시나 다운로드 받고 설치후에 윈도우즈를 다시 시작하면서 상당히 많은 넘들을 설치한다는...
( 머, 루머로는 MS가 다른 브라우져의 속도를 떨어틀이는 기능까지 새롭게 보강한다는 웃기지도 않는 이야기도 돌지만.. ~.~ )
좌우당간... 탭에 기능배치는 참 많이 합니다.
일반 PC에서는 화면이 넓으니.. 상관없겠지만, 노트북과 같은 혹은 넷북과 같은 작은 화면에서는 번거롭죠...
하여간 MSN로그인을 비롯한 잡다한 서비스들을 모두 한 곳에서 불러 볼 수 있으니...
그것은 장점에 해당되겠네요.
그리고,,, 요즘 가장 꿈꾸는자에게 마음을 들게한 Safari...
깔끔한 구글의 디자인을 잘 받아들인...
뉴페이스죠.
속도는 정말 최강인듯합니다. 화면의 디스플레이하는 것은...
다른 어떤 브라우져보다도 ...
그리고...
구글크롬의 장점은 역시.. 깔끔함...
군더더기 없는 기능이 없는... 심플한 브라우져 자체의 강한 모습이 보이고...
자 다른 것은 모르겠습니다만...
IE의 모든 탭기능을 꺼버린 상태에서 3개의 브라우져의 최소치를 볼까요?
저는 다른 것은 모르겠지만, 화면에 배치되는 사이즈를 가장 중요시합니다.
아마도, 그러한 것이 개발사가 사용자들을 얼마나 이해하고 만들었는지에 대해서 가장 많은 것을 판단하게 하는 기준이 아닐까요?
크롬, IE8, Safari의 순서입니다.
분명, 크롬의 공간이 가장 적습니다. 그리고, 사파리, IE8의 순서인데...
윈도우즈의 캡션부분을 크롬과 Safari는 가능한 크기를 줄인데 비하여, IE8은 기존의 표준을 지키고 있어서 벌어진 차이가 아닌가합니다.
이러한 UI의 설계 사상은 화면을 Max했을때에 좀더 확연하게 구분됩니다.
구글 크롬의 경우에는 윈도우즈의 기본캡션은 사라지고 탭이 가장 상단에 배치된 상태로 변하고, 주소창이외에는 보이지 않는 가장 큰 공간을 배치해줍니다.
아마도, 이러한 설계 사상은 이후로도 변하지 않을 것으로 보이죠.
그리고, 윈도우즈 IE8은 자신들이 만들어 놓은 윈도우즈의 기본표준을 어길 수 없겠죠?
역시, 캡션과 주소창, 그리고, 탭... 아마도, 자신들의 표준에서 표현할 최소한의 것들이라고 보입니다.
즐겨찾기와 같은 전통적인 것들을 상단에 배치한것도 그러한 이유가 아닌가 합니다.
그럼, Safari는 어떨까요? 이번에 새롭게 업그레이드된 Safari는 구글의 캡션부분의 탭영역에 대한 디자인을 받아들이는 유연함을 보였다고 할까요? 하지만... 확실하게 구글의 UI철학보다는 좀더 회사틱(?)한 느낌이 보이는 점을 보이고 있습니다.
다른 기능들에 대해서는 워낙에 많은 분들이 서술하고 있는 점들이 많아서리.. 저는 그런 부분에 대한 글은 빼고..
그냥, UI의 설계 철학에 대한 내용들을 살펴보았습니다.
총평을 내자면...
IE8은 자신들이 기준과 표준을 만들고 있다는 생각을 아직 버리고 있지 못하고 보입니다. 그 고집스러움이 결국, 이러저런 서비스들을 뭉쳐놓는 복잡함을 가중하고 있다는 안타까움을 가지게 한다고 할까요?
Safari는 분명 디자인을 전문적으로 전면에 내세우고, 타 회사의 장점마져도 흡수하려는 혁신적인 생각을 설계사상으로 가지고 있다는 점은 정말 놀랍다고 생각하지만, 역시... 자신들이 세운 기준에는 순응하는 조금은 안타까운 마음이 보입니다.
크롬은... 일단, 파괴적인 깔끔한 디자인... 어찌보면, 미니멀리즘 적인 입장에서 본다면, 크롬과 같은 디자인이 스티브잡스를 통해서 표현되었어야 하지 않을까 합니다. 아마도, Safari는 스티브잡스가 직접 컨트롤하는 것 같지는 않는것 같다는... 그런 생각을 가지게 합니다.
머... 꿈꾸는 자의 취향으로 본다면...
Safari에 구글 크롬 처럼 최소화 할 수 있는 기능정도만 제공해준다면 가장 좋겠습니다.
~.~
2009년 3월 18일 수요일
클라우딩의 환상에 너무 빠져들 필요는 없다. 다만, 필요한 곳에 쓸뿐...
IT세계에 오랫동안 있으면서 느끼는 점은... 이곳도 세상살아가는 수 많은 다양한 방법의 이야기들이 무수하게 전해지고 이야기가 되고 있다는 점이다.
그리고, 이 곳에서도 유행이라는 것이 존재하고, 스타일이라는 것도 있고, 문화로 만들어지거나 특정 영역에서만 존재하는 법칙이나 규칙, 문화등이 아주 세분화되어 있기도 하다. 전반적인 시류를 꽤뚫는 철학적인 바탕까지, IT세계에는 사업적인 것과 사람, 사회까지 철학적인 배경으로 문제를 해석하는 방법까지 이제는 인간사회의 한축으로 크게 성장한것 같다.
어제도 구글과 결합한 세일스포스닷컴과 IDC Korea가 주관한 '클라우딩 컴퓨팅 컨퍼런스 2009'에 다녀왔다. 나름 흥미있는 소재들이고 그 역활과 담당해야할 한 축의 미래에 대한 여러가지 이야기들이 나와서 아주 즐거운 시간이었다.
다만... 어떤 신개념이건 이야기되어지는 철학적인 내용이건... 그 환상에 너무 빠져들 필요도 없고, 다만.. 호기심있게 그것들을 바라보는 시선정도는 많이 필요하다는 것을 느낀다.
국내의 IT환경을 약간 외부의 시선으로 바라보면, 너무 유행에 민감한 측면들이 보인다. 물론, 여러가지 이유와 시장의 여건들이 있겠지만, 꿈꾸는자가 생각하는 가장 큰 이유는, 시장의 협소함으로 인한, 유행의 창출과 시스템 갈아업기와 같은 영업적인 시선등의 복합적인 대한민국 IT의 고질적인 병폐까지 많이 뒤섞여 있는 편입니다.
그나마... 요즘은 엉터리 전문가들이 잘못된 기술이나 철학적인 배경들을 국내에 전파하는 경우는 많이 줄어들었습니다. 모두다 인터넷이 발달해서 그런것이니... ~.~ 정말 다행이죠.
어제도 컨퍼런스가 끝나고, 몇가지 나온 질문중에서도 아주 오래된 고전스타일의 질문... 대표적으로 ASP와 클라우딩의 차이점이나, 용어에 대한 혼란등...
저도 몇가지 질문하고 싶었지만, 너무 공통적으로 궁금해하는 내용이 아니라는 생각에 굳이 질문을 하지는 않았습니다. ~.~
자.. 그렇다면, IT 아키텍트 일을 하고 있는 저의 입장에서 바라본 클라우딩에 대한 작은 끄적임을 끄적거려볼까요?
~.~
저는... 클라우딩의 미래에 대해서는 어느정도 공감합니다. 그리고, 그 유용성에 대해서도 정말 생각의 발상이라는 측면과, 세일스포스닷컴이 준비한 그 비즈니스 모델을 적극적으로 저의 비즈니스 영역에 사용하고 싶다라는 생각을 하게 합니다. ~.~
다만, 전체 시스템을 모두 클라우딩으로 가져갈 필요도 없을 뿐... 적절한 분석과 배치를 통해서 클라우딩을 필요 서비스의 위치에 배치하게되겠죠. 하지만, 그동안 전통적으로 구축한 시스템과의 연계성이 더욱더 중요해지고, 신규 서비스의 확장에 대해서도 좀더 많은 고려가 될 것으로 보입니다.
이번에 세일스포스의 포스닷컴에서 Facebook과 연계되는 내용을 보고서는 나름 즐거운 생각이 들었습니다.
머랄까요? 내부 정보시스템과 웹2.0의 만남.. 그리고 소셜네트워크와의 접목등을 풀어 낼 수 있는 매쉬업 세상에 대한 재미를 느꼈다고 할까요?
그리고, 오픈소스의 미래의 정점과 그 시장의 유료화 모델로써의 모델과 구글앱스와의 연계성, 구글기어스등의 프레임워그와 실 서비스의 결합된 모습들... 프로토타입모델을 적극적으로 시도할 수 있는 것까지... ~.~
정말 즐거운 상상과 해당 서비스를 조합하고 있는 제 머릿속을 그려보면... 대단히 행복한 시간이었다고 할까요?
머.. 꿈꾸는 자의 생각은 그렇습니다.
정보의 흐름을 내부 조직간의 흐름만 고려하신다면 굳이 클라우딩까지 가지 않아도, 현재까지 만들어진 수많은 개념이나 솔루션등을 통해서 그리 어렵지 않게 시스템을 구성할 수 있습니다.
하지만, 외부의 흐름과 고객의 흐름, 그들과 연동할 수 있는 정보 흐름까지 고려한다면...
클라우딩의 개념을 어느정도 선까지는 정보시스템의 구조설계에 반영하는 것도 충분한 고려사항이 된다는...
그런 끄저거림을 해본다고 할까요?
클라우딩은 미래라기 보다는...
그 미래를 가지 위한 또 하나의 디딤돌의 역활을 할 것으로 생각되어집니다.
단순하게 내 시스템의 흐름을 다른 곳과 유동적으로 유통할 수 있는 생각의 발상전환을 하게 하는
중요한 수단이 아닌가 하는 생각도 듭니다.
~.~
머... 결론적으로는...
필요한 곳에 배치되는 것은 해당 정보시스템의 컨셉이나 철학에 맞다면...
그 위치에서 살아남겠죠.
그리고, 중요한 역활을 할 것이구요.
2009년 2월 16일 월요일
[SA강좌] Part 4-34 상세 설계에서 해 야할 작업
상세 설계에서 해 야할 작업
상세 설계는 개념 설계를 구현이 가능한 수준의 설계 산출물로 변환하는 작업이다. 다음과 같은 작업을 수행한다.
-
개념 설계의 클래스에 대한 속성 타입 설정
-
오퍼레이션의 매개변수와 반환값 설정
-
클래스의 relation을 association 클래스 등으로 구체화
-
메커니즘을 구현하기 위한 클래스 추가
-
설계 패턴이 적용되는 클래스 추가
-
DB 전문가와 협의하여 엔터티 클래스의 상속 제거, 정규화
-
양 방향 association을 단 방향으로 수정
-
불필요한 association 제거
-
PK와 FK 등 키 설정
-
오퍼레이션 중 DB에서 구현할 것을 표시함(stored procedure, trigger, check등)
-
transaction, 보안, isolation level을 위한 stereotype 설정
-
오퍼레이션에 대한 알고리즘 작성
[SA강좌] Part 4-33 데이터베이스 관련 상세 설계 산출물
데이터베이스 관련 상세 설계 산출물(Database Modeling in UML)
DB와 관련한 설계 산출물 정의는 아래와 같다.
그림 Ⅴ-36. DB 설계 산출물 정의
그림 Ⅴ-37. 클래스, 속성 그리고 오퍼레이션
그림 Ⅴ-38. UML Class model notation
그림 Ⅴ-39. Aggregation Relationships
DB설계 과정 시 클래스들과의 관계(association), 상속(inheritance) 그리고 집합(aggregation)을 포함시켜 클래스 모델을 작성한다. Model-View-Control 설계 패턴을 사용하여 지속성(persistent)을 요구하는 클래스를 식별한다.
그림 Ⅴ-40. UML Relationship
식별된 지속성 클래스에 대하여 관계형 테이블 맵을 작성한다.
그림 Ⅴ-41. 클래스와 테이블의 매핑
[SA강좌] Part 4-32 서버 관련 상세 설계 산출물
서버 관련 상세 설계 산출물
서버 관련 엔터티빈 설계 정의는 아래와 같다.
그림 Ⅴ-34. 엔터티 빈 설계 정의 예제
서버 관련 세션 빈 설계 정의는 아래와 같다.
그림 Ⅴ-35. 세션 빈 설계 정의 예제
서버 관련 설계 산출물 정의시 세션빈에 대한 알고리즘 설계서와 시퀀스 다이어그램을 포함하여야한다.
[SA강좌] Part 4-31 UI 상세 설계 산출물
UI 상세 설계 산출물
UI 상세 설계 산출물 구조는 아래와 같다.
그림 Ⅴ-32. UI네비게이션 모델
UI에 대한 화면 정의는 아래와 같다.
|
| |
|
화면 개요 |
병원 시스템을 사용할 환자가 시스템의 사용자로 등록하기 위한 화면으로 크게 기본정보, 연락처 정보, 기타를 입력하고 등록을 요청한다. |
그림 Ⅴ-33. UI 화면 정의 예제
화면 구현 방법 기술
-
화면의 입력 제약 사항
이름은 20자리로 제한하시요.
주민등록번호는 14자리로 제한하시요.
생년월일은 화면에서 받은 데이터를 YYYYMMDD의 형식으로 저장하시요.
성별은 남자는 string "M", 여자는 string "F"로 저장하시요.
혈액형은 "A","B","AB","O"로 구분하시요.
RH형은 "RH+","RH-"로 구분하시요.
우편번호는 10자리로 제한하시요.
주소는 두줄이며 첫번째 줄은 집주소, 두 번째 주소는 직장 주소가 들어갑니다. 모두 50자리로 제한하시요.
집전화번호와 직장 전화번호는 20자리로 제한하고 –를 사용하여 번호를 구분하시요.(예: 02-3060-4050)
이메일은 20자리로 제한하시요.
개인 및 가족 병력은 100자리로 제한하시요.
-
알고리즘 설계서
PatientValue 객체를 생성한다.(예 PatientValue patient = new PatientValue() )
PatientValue 객체의 속성에 화면에서 입력한 값을 넣는다.
(address1: 집주소, address2: 회사주소, bloodType: 혈액형, citizenNum: 주민등록번호, dateOfBirth: 생년월일, email: 이메일, gender: 성, patientName: 이름, phoneHome: 집 전화번호, phoneOffice: 사무실 전화번호, thType: RH 타입, zipCode: 우편번호, note: 개인 및 가족 병력)
PatientControlBean.registerPatient를 호출하고 입력값은 PatientValue 객체를 넣는다.)
3을 처리할 때 화면의 로직에서 TX의 시작과 끝을 명시하지 말 것(이미 PatientControlBean에서 tx를 시작하고 끝내도록 만들어져 있습니다.)
PatentControlBean.registerPatient에서 넘어온 exception을 화면에서 잡아서 messagebox로 뿌려줄 것.(exception이 발생하면 환자 정보 화면으로 변경되지 않습니다.)
3이 정상적으로 처리되면 리턴값 PatientValue 객체를 받고 환자 정보 화면으로 바뀌도록 할 것
환자 정보 화면은 PatientValue 객체를 사용하여 화면을 보여줄 것
환자 정보에서 진찰등록증 보기를 누르면 진찰 등록증 화면이 popup으로 뜨고 등록번호는 PatientValue 객체의 patientCode 속성을 사용하여 진찰등록증 화면을 보여줄 것.
취소 버튼을 누르면 환자 등록 화면에 들어간 데이터가 삭제되고 빈 화면이 보이도록 하시요.
[SA강좌] Part 4-3 상세 설계 산출물
상세 설계 산출물
UML 표기법을 최대한 활용하고 개발자들이 상세 설계 문서를 보고 개발을 진행할 수 있도록 하는 상세 설계 산출물을 정의한다.
그림 Ⅴ-31. 설계 산출물 구조
2009년 2월 9일 월요일
소프트웨어 개발자 신고제도??? 차라리.. 개발자들이 따로 평가하자!
머... '삽'을 좋아하시는 어떤 분과...
이번에 시행된다는 '소프트웨어 개발자 신고'제도...
그 전에도.. 끄쩍 끄적 글을 써서 그 문제점에 대해서 이야기했었는데...
오늘 그 내용들을 자세하게 살펴보니...
정말 웃기는 것이 하나둘이 아니군요.
'근무경력확인서'와 '기술경력확인서'라는 것이 필요한데...
이 넘들의 서류에...
별~~ 확인절차들을 다 거쳐야 하네요.
그것도...
각 개발자들이 알아서!!!
ㅡㅡ;
http://es.sw.or.kr/
궁금하신 분들은 들어가서 함 보시기를...
정말 웃긴 코미디같은 내용들..
1. 폐업된 회사들의 직인을 못받으면 80% 인정...
머야? 기술 없어서 망했다는 평가인가?
2. 국가기술자격증이 없는 동안의 경력은 50% 인정...
머야? 국가기술자격증이 없으면 개발도 하지 말라는 것인가?
3. 비 SW업체의 경우 'SW기술연구 전담부서확인서'를 받으라구?
머야? 지금 장난하슈? 해당 업체 찾아다니면서... 아쉬운 소리해야하겠네요.. ㅡㅡ;
4. 머! 발주처의 직인까지 받으라구?
머야!!!! 갑,을,병,정을 거쳐서... 페이퍼 컴패니까지 거친 소심한 프리랜서들은 우짜란 말인가?
ㅡㅡ;
5. 머야!!! 서류는 직접방문과 우편접수만 하라구?????
이넘들이 ㅡㅡ; IT랑 관계 있는 거야 없는거야????
6. 수수료... 한시적으로 뮤료지만... 필요시 내라구??
ㅡㅡ; 그래.. 돈 많이 받아서 부자 되세요~~
.
.
.
차라리...
국내의 개발자 커뮤니티에 계신 많은 분들이 모여서...
조금 더 건설적인 방법으로
경력을 인정받을 수 있는
단체를 설립하면 어떨까 하네요.
이런 말도 안되는 '행위'를 하는...
정말...
이거는 개발자들 가슴을 난도질 하는 것도 아니구...
정부에서 이런 일하는 것...
하든지 말든지...
무시하고...
차라리..
소프트웨어 개발자들 끼리...
별도로 '사단법인'만들어서...
개발 개발자들의 경력을 인정받을 수 있고...
그 능력을 검증 받을 수 있는..
그런 제도를 만듭시다.
아니면...
각 개발자 커뮤니티에서 인정받을 수 있는
제도를 각자 만드는 것이 훨씬 좋지 않을까요?
ㅡㅡ;
이러니...
닌텐도같은(!) 것은...
누구도 못만들지..
ㅡㅡ;
2009년 1월 29일 목요일
C/C++과 Flash의 조화... Alchemy... 오호!
Adobe의 연구 프로젝트중에 하나 Alchemy...
델마당에 들어가보니 재미있는 소식이 있어서 자료들을 검색해보니...
제법 꽤! 수준높은 수준까지 올라가있다.
http://www.arcadenoid.com/doom.html
다른것은 다 집어치우고... Doom을 Flash로 변화시킨것을 보면...
정말 멋지다.
ActionScript VirtualMachine(AVM2)용으로 컴파일할 수 있는 프로젝트인데...
http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf<- 상세 문서는 이넘...
http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-flash-9-and-avm2/ <- 이문서도 참조할만하다.
연구의 바탕자체는...
Flash 9에서부터 시작해서 Flash Player 10과 Adobe AIR 1.5에서 구동가능한 SWF or SWC형태로 컴파일 할 수 있게 해주는것으로써, GCC를 이용해서 LLVM(Low Level Virtual Machine)으로 변화시킨후에, 이 넘을 AVM바이트 코드르 변경시키는 과정으로서 완성된다.
LLVM프로젝트도... Java의 JVM처럼 가상머신위에서 명령어 집합 + 형식 시스템의 3번지 코드 방식으로 만들어지는 일종의 가상코드이다. 내부적으로 정수이지만 파생된 포인트, 배열, 벡터, 구조제, 함수등의 5가지를 통해서 표현된다. 어찌보면 그 자체가 C++의 클래스를 받아들일 수 있는 구조가 되어있다고 볼 수 있다.
C++의 클래스를 구조체 + 함수, 함수에 대한 포인터로 변형할 수 있기 때문이다.
호~ 발상이 멋지죠?
C와 C++ -> LLVM -> SWF라...
머.. 가장 중요한것은 AVM2가 사실 오픈되었다는 것...
그래서, 이 방식을 맞추면...
어떤 언어이던지 가능하다는 이야기인데...
이거...
새로운 플랫폼의 방향을 제시하는 것 일 수도.. ㅎㅎ
좌우당간...
좀더 적극적으로 활용한다면...
다른 언어들도 충분하게 가능하다라고 이야기할 수 있는데.. ~.~
다양한 확장이나...
고려대상이 될만하겠네요...
아...
결론적으로는...
AVM2를 Java의 JVM의 레벨까지 끌어올리겠다는
고차원적인 발상인듯..
ㅎㅎ
많은 것을 버리는 것 같지만...
가장 많은 것을 얻는
Adobe의 전략이 멋집니다.
~.~
AVM2관련 문서를 살펴보니...
ActionScript Byte Code (ABC) Format에 대한 이야기가 있고...
세부적인 명령어들에 대해서도 나열되고 있네요...
좀더 상세한 내용들은...
아래의 블로그를 가보세요.
~.~
http://jidolstar.com/blog/archives/356 <- C/C++ Flash 플랫폼과의만남, Alchemy 1부
http://jidolstar.com/blog/archives/436 <- Adobe Alchemy 속도 테스트
자세하게 나와있는 글들도 체크할만하다.
ps~~
오호...
구글링을 해보니...
꽤 많은 곳에서...
pascal과 접목하려고 시도하고 있네요...
하긴..
어렵지는 않을테니...
ㅇㅇ;
2009년 1월 22일 목요일
웹서비스의 진화와 ERP, CRM을 구글앱스로...
우리나라에도 세일즈포스닷컴이 상륙했다. 더더군다나... 별도의 기업홈페이지를 가지기 보다는 Tistory에 기업의 소개내용들이 담겨져있다.
http://pietechnology.tistory.com
'파이테크놀로지'라는 이 기업은 굳이... 온라인에 큰 비용을 쓰지 않고도, 온라인 마켓에 홍보를 위한 전략적인 개념을 변화시킨것이다. 하긴... 뭐, 굳이 홈페이지가 필요하랴... Tistroy에 구축하면 그만인것을...
해당 블로그의 기업대표의 인사말에 적힌것처럼... 기업의 '의지'가 담긴 모습이라고 생각하면... 이 역시 멋진 변화가 아닐까 한다.
구글 솔루션 마켓플레이스는 웹기반 기업용 솔루션의 강자인 세일즈포스닷컴과의 제휴로 정말 무시무시한 괴물로 변해갈 것으로 보인다. Gmail을 비롯하여 캘린더, 구글문서, 구글 토크까지...
현재 4만여개의 기업고객이 사용하고 있는 세일즈포스닷컴의 역량에...
아.. 스카이프도 결합한다고 하는데... 통신까지라... ~.~
아래의 동영상은 구글앱스의 홍보동영상이다... 잘 설명된 내용이라서...
함 보면 좋을듯...
2009년 1월 15일 목요일
대한민국에서 소프트웨어 개발자로 산다는것... (1)
요즘은 블로그에 글 올리는 재미가 쏠쏠합니다. 머랄까... 말을 배설하는 쾌감을 느낀다고나 할까요? 그런데... 제 블로그에 올라온 글들을 보니... 정작 제가 속해있는 소프트웨어 개발에 대한 내용들은 '소프트웨어 아키텍처'에 대한 내용빼고는 그다지 많은 것 같지 않습니다.
그래서... 오래간만에... 대한민국 소프트웨어 개발자에게 '소프트웨어 개발자로 사는 것'에 대해서 끄적거려 보려합니다.
뭐부터 시작해야할까요? 뭐.. 보통 이런 류의 글을 쓸때에는 자기소개를 하는 것이 먼저겠죠?
음,.. 개발경력이라... 컴퓨터를 처음 만진것은 국민학교 6학년 졸업때쯤 부터 시작해서... 중학교 2학년때에 정보처리 기능사취득하고, 그 사이사이... 플밍 알바도 좀 하고... 91년 정보처리 기사자격증 취득해서... 병특생활하다가, 고난의 병특길을 포기하고, 공군에서 전산병으로 제대했습니다.
그후로... 소프트웨어 개발자의 길을 계속 걸어오고 있는데... 순수하게 소프트웨어 개발을 한 경력만 따져본다면...
군대 가기전 2년 병특시절, 전산병생활 3년, 패키지개발 및 연구소생활 5년, 대형SI개발 3년, 소프트웨어 개발 및 IT경영 3년 정도 되겠네요.
나름 파란만장한 IT의 경력을 가지고 있게되었습니다. ~.~
자그마한 통신사의 경품 당첨 프로그램 부터, 백억 넘게들어간 대형SI 프로젝트에서 기술부분을 책임지기도 하고, 원천기술적인 미들웨어나 라우터에 들어가는 플밍이나 설계도 해보고, 아... 온라인 게임개발도 해봤네요. ~.~
거기에 초보시절에는 하드웨어 엔지니어에 어셈블리까지 다루어봤으니...
정말 해볼만한 것은 다 해본듯합니다.
또... 나름 운이 좋았다고 생각하는 것은 실제 사회생활을 나와서... 어느정도 경력이 쌓이면서 IT붐이 일어서 더더욱 좋은 경험을 한것이고, 군대에서는 계룡대에서 군의 전체적인 정보시스템의 구축실무와 업무내용을 바라보는 시야도 생겼고... OMG에 다니면서 방법론이나 UML에 대한 노하우까지...
참 다양한 경험을 습득했습니다.
나이 30전에는 정말 월요일에 출근해서 토요일날 퇴근하는 무지막지한 생활을 즐기기도 했으니까요. 그사이 사이 참으로 많은 결단을 내릴 기회가 많았죠.
그간 결단을 내린것을 따져보면.
1. 병역특례업체에서 고생하기 보다 군대를 가기로 결정한것.
2. 건설설계쪽 소프트웨어 개발사에서 독립해서 테크니션쪽으로 방향을 정한것.
3. 커뮤니티의 대표가 되어서 인맥을 넓히고 명성도 얻게 된것.
4. 개발아이템을 확고이 해서 개발회사를 설립하고, 내 제품을 들고 라스베가스 컴덱스에 나가본것.
5. OMG에 활동하면서 세계최고 수준의 개발자들과 만나본것
6. 소프트웨어 아키텍처를 선택하고 그에 필요한 스킬을 연마한것.
7. 적당한 시기에 개발자의 미래에 대해서 생각해본것.
나름 좋은 결단을 내린 것이라고 생각하는데...
또 뒤돌아보면 잘못된 판단을 내린 경우도 많았습니다.
1. 사업파트너를 만나면서 사람의 됨됨이를 고려하지 않았던 점.
2. 정치적인 역학관계의 매력에 빠져서 순수 개발자로써 오버한점.
3. 비즈니스의 마무리를 해야하는 시점에서 같이 일한 동료들을 일일이 챙겨주지 못한점.
4. 중요한 결단이 필요할때에 남을 공격할 기회가 있으면 해야했는데 그냥 포기한점.
살아가면서...
특히나 소프트웨어 개발자로 살아가면서...
좋은 판단, 나쁜 판단...
결국 다 제가 하는 것이고, 그 결과에 대해서 본인이 책임지는 것이더군요. 이제는, 나이도 40대를 바라보는 시야에서 개발자 보다는 IT를 기반으로 한 경영관리쪽의 일을 하고는 있지만.
제가 살아온 인생길을 뒤돌아보면... 정말 많은 경험을 한듯 합니다.
그런데, 재미있는 것은 소프트웨어 개발자로 살아오면서 느낀것은... 개발자들은 참 많은데 같이 일하고픈 동료들은 그렇게 많지 않았다는 것.
취업난이다, 구인난이다... 다 공감합니다.
어느것이 먼저라고 이야기하기 힘들정도로 복잡한 사회구조를 가지고 있죠.
경험과 스킬이 풍부하고 거기에 학벌까지 좋은 사람들도 많은 것을 보면...
머.. 그런 사람들은 그 사람이 필요한 자리에 가니까요.
생각보다... 실력이 뛰어난 사람은 적은것 같습니다.
어느 곳에서나 '능력'이 탁월한 사람들은 대우를 받으니까요.
머... 이렇게 주절 주절 쓴것은...
후배개발자들에게 이런 이야기를 해주고 싶어서 입니다.
'자신의 능력에 대해서 얼마나 정확하게 알고 있는가?'
능력이상의 일을 도전하는 도전정신도 중요하고...
자신의 스킬을 업그레이드 하는 것도 중요하고...
'실력'에 대한 열망을 가지는 것도 중요합니다.
그런데... 여기서 이야기하는 '능력'에서 가장 중요한 것이 무엇인지 아십니까?
그것은 '커뮤니케이션' '소통'능력입니다.
개발자들에게 가장 중요한 것은 다른 개발자들과 어떻게 일하고, 그사람이 나를 어떻게 느끼고... 내가 다른 사람들을 어떻게 이해할 것인가에 대한 것들입니다.
정말 살벌한 이야기를 하자면...
요즘 소프트웨어 개발 기술은 정말 평준화 되어있고...
수많은 자료들에 대해서 습득하고 약간의 경험과 시간이 주어지면...
할 수 있는 일이 대다수입니다.
특히나... 우리나라의 현실에 있어서... 특수하고 복잡한 일을 하는 경우는 정말 드물죠.
적당한 일에...
적당한 대우를 받는...
그런 곳이 더 많다는 것이죠.
그럴 경우에 '나'를 돋보이게 하는 것이..
바로 '커뮤니케이션'..
'소통능력'이...
가장 최고의 대우를 받게 해준답니다.
'소프트웨어 개발자'에게 있어서
사람이라는 개발자들과 어울려 일하는 곳에 가장 중요한 것은...
바로.. '그'... '소통능력'입니다.
그것을 어떻게 만들어야 하는지는 다음번에... ~.~
... To be Continued
2009년 1월 14일 수요일
[SA강좌] Part 4-24 설계 패턴 적용 방법
설계 패턴 적용 방법
설계 패턴을 적용하기 전에 컨트롤러는 도메인 객체를 호출하기만 할 뿐 업무 로직을 가지고 있지 않다고 생각한다. 즉 도메인 객체가 비즈니스 로직을 나누어 가지고 있다.
도메인 객체는 Transaction Script, Table Module, Domain Model로 구별되며 가장 단순하게 구현할 수 있는 방법은 Transaction Script이다. Domain Model은 가장 익숙해지기 어려운 방식이다. 그러나 Domain Model을 사용하면 복잡한 모델도 쉽게 구현할 수 있다. 또한 Domain Model은 데이터베이스와 연결하는 부분이 복잡하다. Table Module은 이 두가지 사이에서 적절한 선택이 될 수 있다.
Data Source Layer에 대해서는 Transaction Script의 경우는 Row Data Gateway나 Table Data Gateway를 사용한다. RecordSet을 사용하고 데이터베이스와의 연결이 자주 끊어지는 경우에는 Table Data Gateway를 사용하는 것이 좋다. Table Modeul은 Record Set이나 Table Data Gateway와 함께 사용하는 것이 좋다. Domain Model의 경우에는 단순할 경우에는 Active Record를 사용하고 도메인 모델과 데이터베이스 연결을 분리할 경우에는 Table Data Gateway나 Row Data Gateway를 사용한다. 모델이 더 복잡한 경우는 Data Mapper를 사용한다.
J2EE의 경우에는 단순한 경우 Session Bean을 Transaction Script로 사용하고 entity bean은 Row Data Gateway로 사용한다. Domain Model을 사용하는 경우는 현재는 entity bean을 사용하는 것이 최상의 방법이다. 이 경우 entity bean은 Active Record로 사용된다. 이 경우 session bean은 remote façade로서 사용된다. 도메인 모델이 더 복잡하면 entity bean을 배제하고 일반 자바 클래스로 구현하면 된다. JDBC row set을 사용하는 경우는 Table Module을 사용한다.
.NET의 경우에는 가장 일반적인 패턴은 Table Module이다. 물론 Domain Model을 사용할 수도 있지만 이것이 .NET의 경우 최선의 선택이다.
Stored procedure는 remote call을 줄이는 좋은 방법이지만 이식성에 문제가 있다. 그러나 성능의 문제가 있을 경우는 도메인 로직을 제거하고 stored procedure로 옮기는 것이 좋다. Stored procedure를 사용하는 가장 좋은 방법은 Table Data Gateway를 사용하는 것이다.
[SA강좌] Part 4-22 Metadata Mapping
Metadata Mapping 패턴의 정의
메타 데이터 안에 OR 매핑에 대한 상세한 사항을 집어넣는다.
그림 Ⅴ-29. metadata mapping 패턴의 구조
OR 매핑을 취급하는 많은 코드들이 데이터베이스의 필드가 객체의 필드와 어떻게 매핑되는가를 정의한다. 결과적인 코드는 복잡하고 동일한 코드가 반복되는 경우가 많다. Metadata Mapping을 사용하면 개발자가 단순한 테이블 형태의 매핑을 정의하여 데이터를 읽고, 쓰고 업데이트하는 코드를 자동으로 생성할 수 있다.
어떻게 작동하는가?
Metadata mapping을 사용하기 위한 가장 큰 결정사항은 메타데이터의 정보를 실행중의 코드에 어떻게 반영하는가이다. 두 가지 방법이 있는데 첫 번째는 코드 자동화를 사용하는 것이고 두 번째는 reflection을 사용하는 프로그램이다.
코드 자동화를 사용하면 입력이 메타 데이터이고 출력이 매핑을 수행하는 클래스의 소스 코드이다.
Reflection을 사용하면 프로그램은 객체에게 예를 들어 setName이라는 메소드를 요청하고 적절한 파라메터를 사용하여 setName을 호출한다.
코드 자동화는 변경사항이 생기면 재컴파일하고 재배치해야 하기 때문에 덜 동적인 접근 방법이다. Reflection을 사용하면 사용자는 매핑 데이터 파일을 변경하고 이미 만들어진 클래스가 새로운 메타데이터를 사용한다. 사용자는 실행중에 이 작업을 수행할 수 있다.
Reflection에서 사용하는 메타 데이터는 XML을 사용하는 것이 좋은 방법이다.
언제 사용하는가?
Metadata mapping은 데이터베이스 매핑을 처리하는데 필요한 작업량을 줄인다. 그러나 셋업하는데 많은 시간이 소요되기 때문에 OR Mapping 툴을 사용하는 것도 좋은 방법이다. 스스로 메타데이터 매핑을 수행하려면 수작업으로 코드 생성기를 만드는데 걸리는 시간을 고려해봐야 한다. Reflection을 사용할 경우는 성능을 고려해야 한다.
[SA강좌] Part 4-21 Single Table Inheritance 패턴
단일 테이블 상속 패턴의 정의
단일 테이블 상속 패턴은 클래스들의 상속도을 다양한 클래스들의 모든 필드를 위한 컬럼을 가진 단일 테이블로 표현하는 것이다.
그림 Ⅴ-28. 단일 테이블 상속 패턴의 구조
단일 테이블 상속 패턴의 설명
관계형 데이터베이스는 다중 상속을 지원하지 않는다. 이러한 이유로 개체들을 데이터베이스에 매핑할 때 상속 구조를 관계의 테이블로 어떻게 표현할지를 고려해야한다. 관계형 테이터베이스에 매핑할 때, 다중 테이블에 있는 상속 구조를 처리할 때 최소의 조인을 할 수 있게 해야한다. 단일 테이블 상속 패턴은 상속 구조의 모든 클래스들의 모든 필드을 단일 테이블에 매핑한다.
단일 테이블 상속 패턴은 언제 사용하는가?
단일 테이블 상속은 상속구조를 관계형 데이터베이스에 있는 필드들의 매핑을 위한 선택 중에 하나이다. 이러한 매핑 패턴의 대안은 클래스 테이블 상속과 컨크리트 테이블 상속이 있다.
단일 테이블 상속의 장점은 다음과 같다.
-
데이터베이스에 대한 고민은 단지 단일 테이블만 있다.
-
추출되는 데이터에 대한 조인은 없다.
상속에 대한 필드의 추가 및 삭제은 데이터베이스에 대한 변경을 요청하지 않는다.
단일 테이블 상속의 단점
직접적으로 테이블을 이용하는 사람들에게 때때로 관련과 비관련 필드에 대하여 혼란을 준다.
몇몇 서브 클래스에 의해 사용되는 컬럼들은 데이터베이스에 대한 공간의 활용을 저하한다
2008년 12월 27일 토요일
[SA강좌] Part 4-20 Serialized LOB 패턴
시리얼라이즈 LOB(Serialized LOB) 패턴
시리얼라이즈 LOB 패턴의 정의
시리얼라이즈 LOB 패턴은 동기화된 개체들을 데이터베이스 필드에 저장된 단일 큰 개체 개체의 그래프를 저장한다.
그림 Ⅴ-27. 시리얼라이즈 LOB 패턴의 구조
시리얼라이즈 LOB 패턴의 설명
시리얼라이즈 LOB 패턴의 예제:XML에 있는 부서 계층을 시리얼라이즈
class Customer ...
private String name;
private List departments = new ArraryList();
class Department ...
private String name;
private List subsidaries = new ArraryList();
이 경우 데이터베이스는 한개 테이블만 가진다.
create table customers(ID int primary key, name varchar, departments varchar)
활동 레코드(Active Record) 패턴과 같이 고객 테이블은 다루어지고, 입력 행동을 가진 데이터 쓰기를 설명한다.
class Customer ...
public Long insert() {
PreparedStatment insertStatment = null;
try {
insertStatment = DB.prepare(insertStatementString);
setID(findNextDatabaseId();
insertStatment.setInt(1, getID().intValue());
insertStatment.setString(2, name);
insertStatment.setString(3, XmlStringer.write(deapertmentsToXmlElement());
insertStatment.execuete();
Registry.addCustomer(this);
return getID();
} catch(SQLException e) {
throw new ApplicationException(e);
} finally { DB.cleanUp(insertStatment);
}
}
public Element departmentsToXmlElement() {
Element root = new Element("departmentList");
Interator i = departments.iterator();
while (i.hasNext()) {
Department dept = (Department) i.next();
root.addContent(dep.toXmlElement());
}
return root;
}
class Department ...
Element toXmlElement() {
Element root = new Element("department");
root.setAttribute("name", name);
Interator i = subsidiaries.iterator();
while (i.hasNext()) {
Department dept = (Department) i.next();
root.addContent(dep.toXmlElement());
}
return root;
}
[SA강좌] Part 4-19 Embedded Value 패턴
내재된 값(Embedded Value) 패턴
내재된 값 패턴의 정의
내재된 값 패턴은 개체를 다른 개체의 테이블의 몇몇 필드들에 매핑한다.
그림 Ⅴ-26. 내재된 값 패턴의 구조
내재된 값 패턴의 설명
많은 작은 개체들은 테이터베이스의 테이블들 처럼 의미적이지 않은 개체지향 시스템 안에서 의미있게 한다. 예로 동시 발생 인식 메모리 개체와 일자 범위를 포함한다. 비록 기본적 생각은 개체를 테이블과 같이 저장하고, 같지 않은 사원은 메모리 값을 테이블이 원한다.
내재된 값은 개체의 값을 개체 소유자의 레코드에 있는 필드에 매핑한다.
내재된 값 패턴의 예제: 값 개체
내포된 값과 매핑되는 값 개체의 예는 아래와 같다. 다음과 같은 필드들을 가진 간단한 요청 클래스로 시작한다.
class ProductOffering ...
private Product product;
private Money baseCost;
private Integer ID;
위의 필드에서 ID 필드는 일치 필드(Identtity Field) 패턴을 사용하고, product 는 일반적 레코드 매핑이다.
class ProductOffering ...
public static ProductOffering load(ResultSet rs) {
try {
Integer id = (Integer) rs.getObject("ID");
BigDecimal baseCostAmount = rs.getBigDecimal("base_cost_amount");
Currency baseCostCurrency = Registry.getCurrency(rs.getString("base_cost_currency"));
Money baseCost = new Money(baseCostAmount, baseCostCurrency);
Integer productID = (Integer) rs.getObject("product");
Product product = Product.find(Integer) rs.getObject("product"));
return new ProductOffering(id, product, baseCost);
} catch(SQLException e) {
throw new ApplicationExcetion(e);
}
}
아래는 업데이트 행동이다. 다시 업데이터에서 간단한 변수이다.
class ProductOffering ...
public void update() {
PreparedStatment stmt = null;
try {
stmt = DB.prepare(updateStatmentString);
stmt.setBigDecimal(1, baseCost.amount);
stmt.setString(2, baseCost.currency().code());
stmt.setInt(3, ID.intValue());
stmt.execute();
} catch(Exception e) {
throw new ApplicationException(e);
} finally { DB.cleanUp(stmt);
}
private String updateStatementString =
" UPDATE product_offerings " +
" SET base_cost_amount = ?, base_cost_currency = ? " +
" WHERE id = ? ";
피드 구독하기:
글 (Atom)