1

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

볼랜드포럼 / 박지훈imp@borlandforum.com

Case Study: 3tier framework based business projectwith Delphi/C++Builder

2

볼랜드포럼

이 세션의 목적 업무 프로젝트에서의 표준화 -> 프레임워크

왜 프레임워크화를 해야 하는가

Delphi/C++Builder vs. Java/.NET 경쟁 웹 개발 방식들과 경쟁하여 살아남으려면 어떻게 할까

Multi-tier 방식의 유용성과 구현 사례 어떤 경우에 Multi-tier 가 유리하며 어떻게 구현할

것인가

3

볼랜드포럼

업무 개발

4

볼랜드포럼

업무 개발의 특성 - 1

일반적인 업무 프로젝트의 2 대 이슈 실무자의 요구 파악 업무 배분 / 일정 준수

화면 단위 개발 화면들간의 연계성 적음 기술적 요구 스펙이 높지 않음 - 요구된 업무 로직 구현이 중요 계약직 , 초급 위주로 개발하는 경우도 잦음

PM/PL 의 역할 일정 관리 , 작업 배분에 치중 기술적 이슈 , 표준 , 통일성의 문제에는 소홀하기 쉬움

5

볼랜드포럼

업무 개발의 특성 - 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

업무 개발 분야에서 언어 / 개발툴 동향 Java(J2EE) - 압도적 다수 .NET - 중 / 소규모 ASP.NET, 소수 ( 확산이 느림 ) Delphi/C++Builder - 특화 분야 프로젝트

실시간성이 필요한 프로젝트 - HTS 등 하드웨어 인터페이스가 중요한 프로젝트 - ITS 등 역동적인 UI 가 필요한 프로젝트

업무 개발과 Web Java 와 Web 은 동반 성장해옴 Java 가 환영 받는 이유 ?

Java 는 방법론 / 프레임워크 표준화와 함께 발전해옴 통상적 업무 개발에 적합 - 시스템 접근성을 거세 => 일정 예측성

=> Java/.NET 에서도 웹의 부족한 UI 에 문제의식 대두

10

볼랜드포럼

업무 개발 – 경쟁 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) 업무 프로젝트에 맞게 property, event 추가 및

제거 기술적 이슈

디자인타임 Object Inspector 에 property가 나타나지 않음

커스텀 폼을 IDE 에 등록하여 해결 RegisterCustomModule()

17

볼랜드포럼

커스텀 폼 클래스 구현TBizForm = class(TCustomForm)protected ( 기존 동작 override)public ( 메소드 추가 )published (property 추가 ) (event 추가 )end;

IDE 에 커스텀 폼 클래스 등록RegisterCustomModule(TBizForm, TCustomModule);

메인 App 에서 클래스 등록RegisterClass (TCF5211);

( 계속 )

18

볼랜드포럼

프레임워크 구현 - 2

화면 프로젝트 - 패키지 (bpl) (dynamic loading) 메인 App 과의 인터페이스 자유로움 IDE 자체와도 자유롭게 연동 ( 디자인타임에도 동작 ) 디자인타임 컴포넌트화도 가능 bpl 로드 - LoadPackage(Path);

커스텀 폼을 로드할 경우 클래스 타입을 인식하지 못한다 ( 무슨 폼 클래스 ).Create ? 화면 bpl 쪽 - RegisterClass() 호출로 클래스 등록 메인 App 쪽 - FindClass() 로 클래스를 얻은 후 폼 생성

19

볼랜드포럼

( 계속 )화면 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 에서 자동으로 업무용 커스텀 폼 / 프로젝트를 생성 개발자가 중요하지 않은 문제에 집중하지 않도록 한다

공통 함수 , 공통 추가 컴포넌트 , 공통 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) 메인 App (exe) -> 화면 bpl 인터페이스는 용이 화면 bpl -> 메인 App (exe) 인터페이스는 곤란 메인 App 의 기능들 중 화면 bpl 과 인터페이스가 필요한

기능은 중앙 bpl 로 분리 DB connection, Access control ... bpl 폼 로딩 및 관리 루틴

22

볼랜드포럼

Multi-tier

23

볼랜드포럼

Why Multi-tier?

소규모 환경에서의 성능은 이슈가 아님 적은 유저 , 적은 부하 환경에서는 2티어가 성능상 유리

데이터는 티어 개수만큼의 경로를 거침 고려사항 - DB 서버 부하 vs. 각 티어 데이터 전달 단계

멀티티어의 장점 보안성 - DB 서버 직접 액세스 차단 , 암호화 / 보안 기능 추가 가능

미들 서버의 존재 - DB 연결 풀링 , 데이터 캐싱 확장성 - 다수의 DB 서버 , 다수의 미들 서버 안정성 /신뢰성 - Load Balancing, Fail Over

멀티티어의 단점 아키텍처가 복잡 , 코드량 증가 디버깅 난점

24

볼랜드포럼

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 TP Monitor 등 상용 미들웨어 제품

고비용 - per 서버 ! 패키지 판매 제품이므로 지원 기능 스펙에 제한

다양한 서버쪽 추가 기능 구현 불가 Delphi 구현은 클라이언트에 국한

금융기관 , 대형병원 등에서 사용 상용 Delphi 미들웨어 컴포넌트 라이브러리

저비용 ( 수백 달러 ) DataSnap 보다 강력한 기능 / 높은 성능 광범위한 기능 추가 가능 kbmMW, RemObjects, RealThinClient, MidWare, ASTA ...

26

볼랜드포럼

Why kbmMW?

kbmMW의 장점 기존 델파이 방식과 유사 높은 성능 (kbmMemTable, 패킷 압축 등 ) 무료 버전 존재 , 소스 제공 ( 상용 ) 다양한 외부 데이터 액세스 / 통신 / 암호화 컴포넌트 등을

지원 Java, C#, PHP 와도 연동 가능 다양한 부가 기능

load balancing, file service, messaging 등 kbmMW의 단점

기능이 너무 다양 -> 제대로 쓰려면 공부할 게 엄청 늘어난다

소소한 버그가 약간 있다 데이터 페이징이 안된다

27

볼랜드포럼

kbmMW 서버 메인 서버 메인은 일반 모듈 형식

TkbmMWServer 컴포넌트 TkbmMWTCPIPIndyServerTransport 컴포넌트

클라이언트와의 패킷 전송 담당 TkbmMWADOXConnectionPool 컴포넌트

DB 커넥션 풀링

28

볼랜드포럼

kbmMW 서비스 객체 서버측 단위 모듈 – 서비스 ( 개별 화면과 대응 )

TkbmMWCustomService일반 클래스 유닛 (pas), 서버측 함수 호출 컨테이너 클래스

TkbmMWQueryService 커스텀 모듈 (dfm+pas), Query/StoredProc 컨테이너 모듈

29

볼랜드포럼

서비스측 컴포넌트

Resolver TkbmMWServerQuery TkbmMWServerStoredProc

30

볼랜드포럼

클라이언트 화면 컴포넌트 TkbmMWClientQuery TkbmMWClientStoredProc TkbmMWClientTransactionResolver

31

볼랜드포럼

Troubleshooting

bpl 은 바이너리 의존성이 대단히 높다 dll 과 달리 클래스 인터페이스이기 때문 특히 Core 모듈 bpl interface 섹션 (not implementation) 주의 ! 전체 재컴파일을 해야 할 경우가 잦을 수

있음=> Core 모듈 클래스에 무분별한 추가 / 변경 금지

32

볼랜드포럼

정리 프레임워크화

표준화의 연장선상에서 진행 가능 보다 효율적인 개발 진행 업계의 트렌드 (C/S 툴이라고 ???)

Multi-Tier 보안성 , 확장성 , 안정성 Java 등과 경쟁하려면 프레임워크화와 병행하면 추가 부하는 크지 않다