델파이/C++빌더 3tier 프레임워크 기반 업무 개발

Presentation on theme: "델파이/C++빌더 3tier 프레임워크 기반 업무 개발"— Presentation transcript:

1 델파이/C++빌더 3tier 프레임워크 기반 업무 개발
볼랜드포럼 / 박지훈 델파이/C++빌더 3tier 프레임워크 기반 업무 개발 Case Study: 3tier framework based business project with Delphi/C++Builder 볼랜드포럼 / 박지훈

2 이 세션의 목적 업무 프로젝트에서의 표준화->프레임워크 Delphi/C++Builder vs. Java/.NET 경쟁
볼랜드포럼 / 박지훈 이 세션의 목적 업무 프로젝트에서의 표준화->프레임워크 왜 프레임워크화를 해야 하는가 Delphi/C++Builder vs. Java/.NET 경쟁 웹 개발 방식들과 경쟁하여 살아남으려면 어떻게 할까 Multi-tier 방식의 유용성과 구현 사례 어떤 경우에 Multi-tier가 유리하며 어떻게 구현할 것인가

3 볼랜드포럼 / 박지훈 업무 개발

4 업무 개발의 특성 - 1 일반적인 업무 프로젝트의 2대 이슈 화면 단위 개발 PM/PL의 역할 실무자의 요구 파악
볼랜드포럼 / 박지훈 업무 개발의 특성 - 1 일반적인 업무 프로젝트의 2대 이슈 실무자의 요구 파악 업무 배분 / 일정 준수 화면 단위 개발 화면들간의 연계성 적음 기술적 요구 스펙이 높지 않음 - 요구된 업무 로직 구현이 중요 계약직, 초급 위주로 개발하는 경우도 잦음 PM/PL의 역할 일정 관리, 작업 배분에 치중 기술적 이슈, 표준, 통일성의 문제에는 소홀하기 쉬움

5 업무 개발의 특성 - 2 업무 개발 프로젝트의 진행 경향 더 나은 방법은 없을까? 단위 화면들 사이에 중복 코드가 많아짐
볼랜드포럼 / 박지훈 업무 개발의 특성 - 2 업무 개발 프로젝트의 진행 경향 단위 화면들 사이에 중복 코드가 많아짐 담당 개발자들 각각의 구현 방법이 다양할 수 있음 로직, 컴포넌트 선택, UI 디자인 백엔드 데이터베이스 구조와의 연계 방법 => 예상치 못한 버그/오동작의 가능성이 높아짐 => 크로스 테스트/디버깅의 어려움 실제 난이도에 비해 인수/인계 부하 증가 요구가 변경되었을 때의 유연성이 낮음 더 나은 방법은 없을까?

6 표준화 이슈 표준 수립의 효과 표준화의 주요 대상 테크니컬 아키텍트의 필요성
볼랜드포럼 / 박지훈 표준화 이슈 표준 수립의 효과 공통 코드 제거/최소화 ⇒ 코딩 및 코드 관리 시간이 줄어듦 공통 기술적 이슈 통합 관리 ⇒ 개발자들이 각각 시간을 소모하지 않도록 크로스 테스트, 인수인계 용이 표준화의 주요 대상 공통 루틴 라이브러리, 허용 라이브러리/컴포넌트 Naming Convention Hungarian? Prefix? Underscore? Camel Case? Pascal Case? 공통 Data Access 방법 메인 App <-> 화면 사이의 interface 코딩 기법의 제어 - 델파이/C++의 과도한 자유도는 생산성 저하 요인 테크니컬 아키텍트의 필요성 트러블슈팅 + 표준화 마스터 – 개발 표준 수립/유지보수 + Framework 개발, 유지보수

7 개발 표준의 프레임워크화 공통 루틴 라이브러리의 한계 프레임워크화 개별 개발자들에게 사용을 강제하기 어렵다
볼랜드포럼 / 박지훈 개발 표준의 프레임워크화 공통 루틴 라이브러리의 한계 개별 개발자들에게 사용을 강제하기 어렵다 무분별한 공통 루틴 양산 - 관리의 어려움 프레임워크화 공통 화면 클래스(들) 화면 객체의 표준 모듈화 exe(X) dll? bpl? 공통 Data Access 방법 공통 Main App 인터페이스 방법 화면 프로젝트와 기본 멤버들의 자동 생성

8 볼랜드포럼 / 박지훈 경쟁

9 업무 개발 - 경쟁 1 업무 개발 분야에서 언어/개발툴 동향 업무 개발과 Web
볼랜드포럼 / 박지훈 업무 개발 - 경쟁 1 업무 개발 분야에서 언어/개발툴 동향 Java(J2EE) - 압도적 다수 .NET - 중/소규모 ASP.NET, 소수 (확산이 느림) Delphi/C++Builder - 특화 분야 프로젝트 실시간성이 필요한 프로젝트 - HTS 등 하드웨어 인터페이스가 중요한 프로젝트 - ITS 등 역동적인 UI가 필요한 프로젝트 업무 개발과 Web Java와 Web은 동반 성장해옴 Java가 환영 받는 이유? Java는 방법론/프레임워크 표준화와 함께 발전해옴 통상적 업무 개발에 적합 - 시스템 접근성을 거세 => 일정 예측성 => Java/.NET에서도 웹의 부족한 UI에 문제의식 대두

10 업무 개발 – 경쟁 2 X Internet, RIA X Internet vs. Native
볼랜드포럼 / 박지훈 업무 개발 – 경쟁 2 X Internet, RIA 웹 기반 업무 개발의 부족한 UI를 보충하는 역할 Backend는 기존의 웹 방법론을 그대로 유지 사용자들의 불만/요구로 최근 급속하게 도입 확산 MiPlatform, Curl, Flex, MS SmartClient, Silverlight X Internet vs. Native 풍부한 UI와 실시간성은 Native 개발의 절대 강점 UI vs. UI의 대결 - Native의 장점 부각 가능 사용자도 더 이상 “웹!”을 외치지 않는다 => Native 개발에 부족한 알파 Framework - 표준화 및 개발 생산성 Multi-tier - 서비스의 안정성, 확장성, 신뢰성

11 볼랜드포럼 / 박지훈 X Internet 사례 – 1. 로그인

12 볼랜드포럼 / 박지훈 X Internet 사례 – 2. 실행화면

13 볼랜드포럼 / 박지훈 X Internet 사례 – 3. 개발툴

14 볼랜드포럼 / 박지훈 X Internet 사례 – 4. 스크립트

15 볼랜드포럼 / 박지훈 프레임워크 구현

16 프레임워크 구현 - 1 커스텀 폼 class (vs. TForm / TFrame)
볼랜드포럼 / 박지훈 프레임워크 구현 - 1 커스텀 폼 class (vs. TForm / TFrame) 업무 프로젝트에 맞게 property, event 추가 및 제거 기술적 이슈 디자인타임 Object Inspector에 property가 나타나지 않음 커스텀 폼을 IDE에 등록하여 해결 RegisterCustomModule()

17 (계속) 커스텀 폼 클래스 구현 IDE에 커스텀 폼 클래스 등록 메인 App에서 클래스 등록
볼랜드포럼 / 박지훈 (계속) 커스텀 폼 클래스 구현 TBizForm = class(TCustomForm) protected (기존 동작 override) public (메소드 추가) published (property 추가) (event 추가) end; IDE에 커스텀 폼 클래스 등록 RegisterCustomModule(TBizForm, TCustomModule); 메인 App에서 클래스 등록 RegisterClass (TCF5211);

18 프레임워크 구현 - 2 화면 프로젝트 - 패키지(bpl) (dynamic loading)
볼랜드포럼 / 박지훈 프레임워크 구현 - 2 화면 프로젝트 - 패키지(bpl) (dynamic loading) 메인 App과의 인터페이스 자유로움 IDE 자체와도 자유롭게 연동 (디자인타임에도 동작) 디자인타임 컴포넌트화도 가능 bpl 로드 - LoadPackage(Path); 커스텀 폼을 로드할 경우 클래스 타입을 인식하지 못한다 (무슨 폼 클래스).Create ? 화면 bpl 쪽 - RegisterClass() 호출로 클래스 등록 메인 App 쪽 - FindClass()로 클래스를 얻은 후 폼 생성

19 (계속) 화면 bpl 쪽 메인 App 쪽 initialization RegisterClass(TCF5211);
볼랜드포럼 / 박지훈 (계속) 화면 bpl 쪽 initialization RegisterClass(TCF5211); finalization UnregisterClass(TCF5211); 메인 App 쪽 type TBizFrameClass = class of TBizFrame; var AIndex: integer; AForm: TBizForm; FrameClass: TBizFormClass; begin ... LoadPackage(PackagePath); FrameClass := TBizFormClass(FindClass('TCF5211')); AForm := TBizForm(FrameClass.Create(AOwner)); Aform.Show;

20 프레임워크 구현 - 3 폼/프로젝트 Wizard IDE에서 자동으로 업무용 커스텀 폼/프로젝트를 생성
볼랜드포럼 / 박지훈 프레임워크 구현 - 3 폼/프로젝트 Wizard IDE에서 자동으로 업무용 커스텀 폼/프로젝트를 생성 개발자가 중요하지 않은 문제에 집중하지 않도록 한다 공통 함수, 공통 추가 컴포넌트, 공통 property 값 등 Uses ToolsAPI Wizard/Creator 인터페이스 구현 클래스 작성 Wizard IOTAFormWizard, IOTAProjectWizard, IOTARepositoryWizard Creator IOTAProjectCreator, IOTAModuleCreator 화면 프로젝트 기본 설정들 미리 적용 lib dir, output dir, run param, version info ...

21 프레임워크 구현 - 4 Core 인터페이싱 데이터모듈 bpl (static loading)
볼랜드포럼 / 박지훈 프레임워크 구현 - 4 Core 인터페이싱 데이터모듈 bpl (static loading) 메인 App (exe) -> 화면 bpl 인터페이스는 용이 화면 bpl -> 메인 App (exe) 인터페이스는 곤란 메인 App의 기능들 중 화면 bpl과 인터페이스가 필요한 기능은 중앙 bpl로 분리 DB connection, Access control ... bpl 폼 로딩 및 관리 루틴

22 볼랜드포럼 / 박지훈 Multi-tier

23 Why Multi-tier? 소규모 환경에서의 성능은 이슈가 아님 멀티티어의 장점 멀티티어의 단점
볼랜드포럼 / 박지훈 Why Multi-tier? 소규모 환경에서의 성능은 이슈가 아님 적은 유저, 적은 부하 환경에서는 2티어가 성능상 유리 데이터는 티어 개수만큼의 경로를 거침 고려사항 - DB 서버 부하 vs. 각 티어 데이터 전달 단계 멀티티어의 장점 보안성 - DB 서버 직접 액세스 차단, 암호화/보안 기능 추가 가능 미들 서버의 존재 - DB 연결 풀링, 데이터 캐싱 확장성 - 다수의 DB 서버, 다수의 미들 서버 안정성/신뢰성 - Load Balancing, Fail Over 멀티티어의 단점 아키텍처가 복잡, 코드량 증가 디버깅 난점

24 Delphi Multi-tier 방법의 선택 - 1
볼랜드포럼 / 박지훈 Delphi Multi-tier 방법의 선택 - 1 DataSnap(MIDAS) 기본 내장 컴포넌트, 추가 비용 없음 Delphi7+ / C++Builder6+ 간편하고 가벼우며 구조 간단 복잡한 업무 구현에는 기능 부족 ECO 기본 내장 프레임워크(Delphi8+), 추가 비용 없음 코드기어의 주력 모델링 기반 개발 방법론 (MDA) 기존 델파이 개발 방식과 다른 방식 .NET 필수! No Win32! No C++Builder 2007부터 VCL.NET 지원 But, way to go. (다음 세미나엔…? ^^)

25 Delphi Multi-tier 방법의 선택 - 2
볼랜드포럼 / 박지훈 Delphi Multi-tier 방법의 선택 - 2 TP Monitor 등 상용 미들웨어 제품 고비용 - per 서버! 패키지 판매 제품이므로 지원 기능 스펙에 제한 다양한 서버쪽 추가 기능 구현 불가 Delphi 구현은 클라이언트에 국한 금융기관, 대형병원 등에서 사용 상용 Delphi 미들웨어 컴포넌트 라이브러리 저비용 (수백 달러) DataSnap보다 강력한 기능 / 높은 성능 광범위한 기능 추가 가능 kbmMW, RemObjects, RealThinClient, MidWare, ASTA ...

26 Why kbmMW? kbmMW의 장점 kbmMW의 단점 기존 델파이 방식과 유사
볼랜드포럼 / 박지훈 Why kbmMW? kbmMW의 장점 기존 델파이 방식과 유사 높은 성능 (kbmMemTable, 패킷 압축 등) 무료 버전 존재, 소스 제공 (상용) 다양한 외부 데이터 액세스 / 통신 / 암호화 컴포넌트 등을 지원 Java, C#, PHP와도 연동 가능 다양한 부가 기능 load balancing, file service, messaging 등 kbmMW의 단점 기능이 너무 다양 -> 제대로 쓰려면 공부할 게 엄청 늘어난다 소소한 버그가 약간 있다 데이터 페이징이 안된다

27 kbmMW 서버 메인 서버 메인은 일반 모듈 형식 TkbmMWServer 컴포넌트
볼랜드포럼 / 박지훈 kbmMW 서버 메인 서버 메인은 일반 모듈 형식 TkbmMWServer 컴포넌트 TkbmMWTCPIPIndyServerTransport 컴포넌트 클라이언트와의 패킷 전송 담당 TkbmMWADOXConnectionPool 컴포넌트 DB 커넥션 풀링

28 kbmMW 서비스 객체 서버측 단위 모듈 – 서비스 (개별 화면과 대응)
볼랜드포럼 / 박지훈 kbmMW 서비스 객체 서버측 단위 모듈 – 서비스 (개별 화면과 대응) TkbmMWCustomService 일반 클래스 유닛(pas), 서버측 함수 호출 컨테이너 클래스 TkbmMWQueryService 커스텀 모듈(dfm+pas), Query/StoredProc 컨테이너 모듈

29 서비스측 컴포넌트 Resolver TkbmMWServerQuery TkbmMWServerStoredProc
볼랜드포럼 / 박지훈 서비스측 컴포넌트 Resolver TkbmMWServerQuery TkbmMWServerStoredProc

30 클라이언트 화면 컴포넌트 TkbmMWClientQuery TkbmMWClientStoredProc
볼랜드포럼 / 박지훈 클라이언트 화면 컴포넌트 TkbmMWClientQuery TkbmMWClientStoredProc TkbmMWClientTransactionResolver

31 Troubleshooting bpl은 바이너리 의존성이 대단히 높다 dll과 달리 클래스 인터페이스이기 때문
볼랜드포럼 / 박지훈 Troubleshooting bpl은 바이너리 의존성이 대단히 높다 dll과 달리 클래스 인터페이스이기 때문 특히 Core 모듈 bpl interface 섹션 (not implementation) 주의! 전체 재컴파일을 해야 할 경우가 잦을 수 있음 => Core 모듈 클래스에 무분별한 추가/변경 금지

32 정리 프레임워크화 Multi-Tier 표준화의 연장선상에서 진행 가능 보다 효율적인 개발 진행
볼랜드포럼 / 박지훈 정리 프레임워크화 표준화의 연장선상에서 진행 가능 보다 효율적인 개발 진행 업계의 트렌드 (C/S 툴이라고???) Multi-Tier 보안성, 확장성, 안정성 Java 등과 경쟁하려면 프레임워크화와 병행하면 추가 부하는 크지 않다