볼랜드포럼: 세미나 자료 관련: BizWorks 프레임워크

	C++Builder \| Delphi \| FireMonkey \| C/C++ \| Free Pascal \| Firebird

경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지

분야별 포럼

볼랜드포럼 홈

회원 메뉴

자유게시판		세상 살아가는 이야기들을 나누는 사랑방입니다.

[13464] 세미나 자료 관련: BizWorks 프레임워크
[cbuilder]	2637 읽음 2007-10-22 10:12

BizWorks_Framework.ppt 1.3MB

지금 세미나 자료 첨부로 올립니다. (14:10)
(폰트가 표준폰트가 아닌 으뜸체로 되어 있습니다. 으뜸체가 없을 경우 좀 깨져보일 겁니다.)

--------------------------------------------------------

제 세션을 들으신 분은 기억나시지만, 제 세미나 세션에서 발표한 내용들을 모두 공개하기로 약속드렸습니다.
여기에는 다음과 같은 것들이 포함됩니다.

1. 발표 자료(ppt)
2. BizWorks 프레임워크 전체의 소스
3. kbmMW 번역한 문서들

ppt 자료는 점심시간쯤에 올려드릴 것이고, 나머지는 내일과 모레 정도에 올리겠습니다.
소스는 이전 회사와 관련된 부분들을 제거하고 안정적으로 동작하는지 테스트를 해봐야 해서, 아마 이틀 정도 정리 시간이 필요할 거 같고요. kbmMW 번역 문서들은 현재 사무실에 가지고 있지 않기 때문에 오늘 밤이나 내일 올려드릴 예정입니다.

소스를 다운받아 보시면 아시겠지만 그렇게 거창한 규모도 아니고, 중급 정도의 개발자시라면 열심히 분석해보면 며칠이면 전체 맥락을 잡을 수 있는 정도의 분량입니다.

소스를 공개하는 것은, 세미나에서 설명드린 취지와 같습니다. 현재 많은 델파이/C++빌더 기반 업무 개발 프로젝트들이 중구난방식으로 개발되어 관리도 힘들 뿐더러 안정성이나 성능도 많이 떨어지고, 더욱이 자바나 닷넷과 같은 다른 개발 환경의 개발자들로부터 무시를 당하기도 하고 경쟁에서 뒤떨어지고 있습니다.

저는 지금껏 OOP에 제대로 된 관심을 가져본 적이 없을 뿐더러, 웬만한 수준의 개발자들에게 기존의 개발 방식에서 OOP로 한번에 넘어가려고 하는 것은 오히려 큰 실패를 가져올 수 있다는 생각을 가지고 있습니다. BizWorks 프레임워크를 개발하는 과정에서 가장 주안점을 가졌던 것도, 프레임워크를 적용하고 멀티티어라는 새로운 방식을 접하면서도 기존 개발자들이 새로 공부해야 할 분량을 최대한 줄인다는 것이었습니다.

따라서 BizWorks 프레임워크도 OOP와는 거의 무관하게 만들어져 있고, 개발자가 이론적으로 공부해야 할 것은 별로 없습니다. 다만 멀티티어 프레임워크의 기반으로 kbmMW를 선택했기 때문에 kbmMW에 대한 기본은 이해해야 할 필요가 있습니다. 세미나에서 kbmMW를 잠깐이나마 설명했던 이유도 그것이고요. 물론 각자의 역량껏 kbmMW외에 다른 멀티티어 방법을 접목하는 것도 그리 어렵지 않습니다.

BizWorks 프레임워크가 유일한 방법은 절대로 아닐 뿐더러, 가장 좋은 방법이라고도 말할 수 없습니다만, 비교적 쉬운 구조에 비교적 적은 부하로 개발팀이 업무에 적용할 수 있도록 단순하게 구성되어 있습니다. 많은 개발 환경에서 접목 시도가 되어 활성화된다면, 오픈소스 프로젝트로 더 발전시켜나가고 포럼 내에도 별도의 전용 공간을 만들어서 제대로 진행할 수도 있습니다. 별도의 Q/A를 진행할 수도 있구요.

물론 더 좋은 방법이 나와서 멋진 선의의 경쟁이 된다면 더 바랄 바가 없겠습니다. 제가 공개하는 목적이 시덥잖은 과시를 하는 것도 아니고, 델파이와 C++빌더로 업무 개발을 하는 분들께 약간의 발전을 위한 자극과 하나의 전환점이 되기를 바래서이기 때문입니다.

ps. BizWorks라는 이름은 방금 붙여봤습니다. 이전까지는 그냥 Biz라고 불렀었는데 넘 일반적인 이름이라 공개 이후에 사용할 이름으로 적당하지 않을 거 같아서 대충 붙인 겁니다.

Trackback : http://www.borlandforum.com/impboard/impboard.dll/trackback?sn=99431

[bkyang] 2007-10-22 10:33 X

코드기어 축하 메세지 동영상 올려주세여~ ^^;

[nasilso] 2007-10-22 10:36 X

기대.. 기대.. 기대됩니다.
졸리긴 했지만.. 개인적으로 제일 좋았던 세션이었습니다.
(졸진 않았어요 ㅋㅋ)

이길남 [hankilit] 2007-10-22 11:02 X

ㅜ,ㅜ
사전등록해놓고서 참석못했읍니다......
꼭 참석하고 샆었는데.....
다른 발표자 분들도 내용 공개를 하시는지 모르겠네요...
아님 등록한 사람들에게라도 메일로 보내 주실 수 있으실지....ㅠㅠ

김도완 [purplecofe2] 2007-10-22 15:54 X

PPT 문서를 보니 패키지 대한 내용이 있던데,

http://pluginmgr.dennislandi.com/

이곳도 참고해보셔요.

[cbuilder] 2007-10-23 03:54 X

오, 좋은 내용이네요. 패키지 다루기를 고민하는 경우가 많지 않으니까 참고할 만한 코드가 좀 보이네요.

그런데.. 제가 진행했던 업무 개발에서의 패키지 폼의 경우와는 좀 다른 경우인 듯 싶습니다. 글을 쓴 데니스 랜디라는 분은 패키지가 로드되었을 때 전역적인(system-wide, application-wide) 노티피케이션이 발생해야 하거나 클래스 네임을 받아오는 것이 어려웠던 상황인가본데, 솔직히 감이 잘 안옵니다.

랜디씨가 이상적인 솔루션이라고 말하는 것은 코드기어에서 TApplication 클래스에 OnClassRegistered 이런 식으로 새로운 클래스가 등록될 때마다 트리거되는 이벤트를 만들어주는 거라고 하는데요. 이벤트 핸들러로는 클래스 타입이 돌아오는.. 그 기능이 없어서 복잡한 컴포넌트를 만든 거라는 얘긴데요. 패키지쪽에서 로드된 직후가 아닌 다른 시점에 클래스를 RegisterClass할 필요가 별로 없을 거 같고, 만약 제가 한 것처럼 initianization 섹션에서 하든지 해서 로드된 직후에 클래스를 등록한다면 이벤트가 무의미하겠죠. 패키지 로드를 호출하는 코드 바로 다음줄에서는 에러가 발생하지 않은 한 이미 클래스가 등록되어 있을 것이기 때문에요.

또, 클래스 타입을 얻어오는 것이 관건이라면, 제 경우에는 무조건 하나의 bpl에 익스포트 폼 하나씩이라는 가정을 했기 때문에(물론 내부 호출 폼은 얼마든지 더 추가할 수 있지만) bpl 이름과 폼 클래스 이름을 같은 네이밍 규칙을 줄 수 있었기 때문에 이슈가 안되었는데요. (예를 들어 패키지 이름이 cl5001.bpl이면 폼 클래스 이름은 무조건 TCF5001이라는 식으로)

예를 들어 패키지 안에 익스포트되는(외부에서 호출할) 폼이 여러개라고 해도, 차라리 특정 이름의 익스포트 함수를 하나 만들어서 폼 클래스들의 이름들을 리턴하도록 하는 것이 더 효율적일 듯 싶습니다. 어차피 패키지를 로드하고 폼 클래스를 얻어내는 절차는 차례로 한꺼번에 하는 것이 효율적이니까요. 한꺼번에 하는 것이 효율적이라는 것은, 어차피 패키지를 동적으로 로드했다면 패키지 핸들을 리스트 형태 등으로 관리해두어야 하기 때문에, 폼 클래스 이름이나 클래스 타입 변수들의 리스트를 같이 가지고 있어도 별 관리상의 부하가 늘어나거나 하지 않거든요.

물론 랜디씨는 아주 특이한 상황이어서 제가 간주한 상황과 아주 다를 수도 있겠지만 말이죠. ^^

한구용 [kyhan] 2007-10-23 11:39 X

이번세미나에 3-tier관련해서 참석을 한건데...정말 좋았습니다.
...잘 만드셨더군요..다음에 기회되면 또 뵙으면 합니다.
좋은 정보 감사합니다.