Transcript BizWorks_Framework

델파이/C++빌더
3tier 프레임워크 기반 업무 개발
Case Study: 3tier framework based business project
with Delphi/C++Builder
볼랜드포럼 / 박지훈
[email protected]
1
이 세션의 목적

업무 프로젝트에서의 표준화->프레임워크


왜 프레임워크화를 해야 하는가
Delphi/C++Builder vs. Java/.NET 경쟁


볼랜드포
럼
웹 개발 방식들과 경쟁하여 살아남으려면 어떻게
할까
Multi-tier 방식의 유용성과 구현 사례

어떤 경우에 Multi-tier가 유리하며 어떻게 구현할
것인가
2
볼랜드포
럼
업무 개발
3
업무 개발의 특성 - 1

일반적인 업무 프로젝트의 2대 이슈



실무자의 요구 파악
업무 배분 / 일정 준수
화면 단위 개발




볼랜드포
럼
화면들간의 연계성 적음
기술적 요구 스펙이 높지 않음 - 요구된 업무 로직 구현이 중
요
계약직, 초급 위주로 개발하는 경우도 잦음
PM/PL의 역할


일정 관리, 작업 배분에 치중
기술적 이슈, 표준, 통일성의 문제에는 소홀하기 쉬움
4
업무 개발의 특성 - 2

볼랜드포
럼
업무 개발 프로젝트의 진행 경향


단위 화면들 사이에 중복 코드가 많아짐
담당 개발자들 각각의 구현 방법이 다양할 수 있음

로직, 컴포넌트 선택, UI 디자인

백엔드 데이터베이스 구조와의 연계 방법
=> 예상치 못한 버그/오동작의 가능성이 높아짐
=> 크로스 테스트/디버깅의 어려움



실제 난이도에 비해 인수/인계 부하 증가
요구가 변경되었을 때의 유연성이 낮음
더 나은 방법은 없을까?
5
표준화 이슈
볼랜드포
럼
표준 수립의 효과

공통 코드 제거/최소화 ⇒ 코딩 및 코드 관리 시간이 줄어듦

공통 기술적 이슈 통합 관리 ⇒ 개발자들이 각각 시간을 소모하지
않도록

크로스 테스트, 인수인계 용이
 표준화의 주요 대상

공통 루틴 라이브러리, 허용 라이브러리/컴포넌트
 Naming Convention


Hungarian? Prefix? Underscore? Camel Case? Pascal Case?

공통 Data Access 방법

메인 App <-> 화면 사이의 interface

코딩 기법의 제어 - 델파이/C++의 과도한 자유도는 생산성 저하
요인
 테크니컬 아키텍트의 필요성

트러블슈팅
+ 표준화 마스터 – 개발 표준 수립/유지보수
+ Framework 개발, 유지보수
6
개발 표준의 프레임워크화

공통 루틴 라이브러리의 한계



볼랜드포
럼
개별 개발자들에게 사용을 강제하기 어렵다
무분별한 공통 루틴 양산 - 관리의 어려움
프레임워크화


공통 화면 클래스(들)
화면 객체의 표준 모듈화




exe(X) dll? bpl?
공통 Data Access 방법
공통 Main App 인터페이스 방법
화면 프로젝트와 기본 멤버들의 자동 생성
7
볼랜드포
럼
경쟁
8
업무 개발 - 경쟁 1

업무 개발 분야에서 언어/개발툴 동향
 Java(J2EE) 압도적 다수
 .NET 중/소규모 ASP.NET, 소수 (확산이 느림)
 Delphi/C++Builder 특화 분야 프로젝트




볼랜드포
럼
실시간성이 필요한 프로젝트 - HTS 등
하드웨어 인터페이스가 중요한 프로젝트 - ITS 등
역동적인 UI가 필요한 프로젝트
업무 개발과 Web
 Java
와 Web은 동반 성장해옴
 Java
가 환영 받는 이유?


Java는 방법론/프레임워크 표준화와 함께 발전해옴
통상적 업무 개발에 적합 - 시스템 접근성을 거세 => 일정 예측성
=> Java/.NET에서도 웹의 부족한 UI에 문제의식 대두
9
업무 개발 – 경쟁 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 - 서비스의 안정성, 확장성, 신뢰성
10
X Internet 사례 – 1. 로그인
볼랜드포
럼
11
X Internet 사례 – 2. 실행화면
볼랜드포
럼
12
X Internet 사례 – 3. 개발툴
볼랜드포
럼
13
X Internet 사례 – 4. 스크립트
볼랜드포
럼
14
볼랜드포
럼
프레임워크 구현
15
프레임워크 구현 - 1

볼랜드포
럼
커스텀 폼 class (vs. TForm / TFrame)


업무 프로젝트에 맞게 property, event 추가 및 제
거
기술적 이슈


디자인타임 Object Inspector에 property가 나타나지
않음
커스텀 폼을 IDE에 등록하여 해결

RegisterCustomModule()
16
볼랜드포
럼
(계속)

커스텀 폼 클래스 구현
TBizForm = class(TCustomForm)
protected
(기존 동작 override)
public
(메소드 추가)
published
(property 추가)
(event 추가)
end;

IDE에 커스텀 폼 클래스 등록
RegisterCustomModule(TBizForm, TCustomModule);

메인 App에서 클래스 등록
RegisterClass (TCF5211);
17
프레임워크 구현 - 2

화면 프로젝트 - 패키지(bpl) (dynamic loading)





볼랜드포
럼
메인 App과의 인터페이스 자유로움
IDE 자체와도 자유롭게 연동 (디자인타임에도 동작)
디자인타임 컴포넌트화도 가능
bpl 로드 - LoadPackage(Path);
커스텀 폼을 로드할 경우 클래스 타입을 인식하지 못
한다



(무슨 폼 클래스).Create ?
화면 bpl 쪽 - RegisterClass() 호출로 클래스 등록
메인 App 쪽 - FindClass()로 클래스를 얻은 후 폼 생성
18
볼랜드포
럼
(계속)
화면 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;
19
프레임워크 구현 - 3

볼랜드포
럼
폼/프로젝트 Wizard







IDE에서 자동으로 업무용 커스텀 폼/프로젝트를 생성
개발자가 중요하지 않은 문제에 집중하지 않도록 한다
공통 함수, 공통 추가 컴포넌트, 공통 property 값 등
Uses ToolsAPI
Wizard/Creator 인터페이스 구현 클래스 작성
Wizard
 IOTAFormWizard, IOTAProjectWizard,
IOTARepositoryWizard
Creator
 IOTAProjectCreator, IOTAModuleCreator
화면 프로젝트 기본 설정들 미리 적용
 lib dir, output dir, run param, version info ...
20
프레임워크 구현 - 4

볼랜드포
럼
Core 인터페이싱 데이터모듈 bpl (static loading)



메인 App (exe) -> 화면 bpl 인터페이스는 용이
화면 bpl -> 메인 App (exe) 인터페이스는 곤란
메인 App의 기능들 중 화면 bpl과 인터페이스가 필요한 기
능은 중앙 bpl로 분리
 DB connection, Access control ...
 bpl
폼 로딩 및 관리 루틴
21
볼랜드포
럼
Multi-tier
22
볼랜드포
럼
Why Multi-tier?

소규모 환경에서의 성능은 이슈가 아님



멀티티어의 장점





적은 유저, 적은 부하 환경에서는 2티어가 성능상 유리

데이터는 티어 개수만큼의 경로를 거침
고려사항 - DB 서버 부하 vs. 각 티어 데이터 전달 단계
보안성 - DB 서버 직접 액세스 차단, 암호화/보안 기능 추가
가능
미들 서버의 존재 - DB 연결 풀링, 데이터 캐싱
확장성 - 다수의 DB 서버, 다수의 미들 서버
안정성/신뢰성 - Load Balancing, Fail Over
멀티티어의 단점


아키텍처가 복잡, 코드량 증가
디버깅 난점
23
볼랜드포
럼
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. (다음 세미나엔…? ^^)
24
볼랜드포
럼
Delphi Multi-tier 방법의 선택 - 2

TP Monitor 등 상용 미들웨어 제품




고비용 - per 서버!
패키지 판매 제품이므로 지원 기능 스펙에 제한

다양한 서버쪽 추가 기능 구현 불가
 Delphi
구현은 클라이언트에 국한
금융기관, 대형병원 등에서 사용
상용 Delphi 미들웨어 컴포넌트 라이브러리




저비용 (수백 달러)
DataSnap보다 강력한 기능 / 높은 성능
광범위한 기능 추가 가능
kbmMW, RemObjects, RealThinClient, MidWare, ASTA ...
25
볼랜드포
럼
Why kbmMW?

kbmMW의 장점







기존 델파이 방식과 유사
높은 성능 (kbmMemTable, 패킷 압축 등)
무료 버전 존재, 소스 제공 (상용)
다양한 외부 데이터 액세스 / 통신 / 암호화 컴포넌트 등을
지원
Java, C#, PHP와도 연동 가능
다양한 부가 기능
 load balancing, file service, messaging
등
kbmMW의 단점



기능이 너무 다양 -> 제대로 쓰려면 공부할 게 엄청 늘어난
다
소소한 버그가 약간 있다
데이터 페이징이 안된다
26
kbmMW 서버 메인

볼랜드포
럼
서버 메인은 일반 모듈 형식



TkbmMWServer 컴포넌트
TkbmMWTCPIPIndyServerTransport 컴포넌트

클라이언트와의 패킷 전송 담당
TkbmMWADOXConnectionPool 컴포넌트
 DB
커넥션 풀링
27
kbmMW 서비스 객체

볼랜드포
럼
서버측 단위 모듈 – 서비스 (개별 화면과 대응)


TkbmMWCustomService

일반 클래스 유닛(pas), 서버측 함수 호출 컨테이너 클
래스
TkbmMWQueryService

커스텀 모듈(dfm+pas), Query/StoredProc 컨테이너 모듈
28
서비스측 컴포넌트



볼랜드포
럼
Resolver
TkbmMWServerQuery
TkbmMWServerStoredProc
29
클라이언트 화면 컴포넌트



볼랜드포
럼
TkbmMWClientQuery
TkbmMWClientStoredProc
TkbmMWClientTransactionResolver
30
볼랜드포
럼
Troubleshooting

bpl은 바이너리 의존성이 대단히 높다
dll과 달리 클래스 인터페이스이기 때문

특히 Core 모듈 bpl
 interface
섹션 (not implementation)

주의! 전체 재컴파일을 해야 할 경우가 잦을 수 있
음
=> Core 모듈 클래스에 무분별한 추가/변경 금지

31
정리

프레임워크화




볼랜드포
럼
표준화의 연장선상에서 진행 가능
보다 효율적인 개발 진행
업계의 트렌드 (C/S 툴이라고???)
Multi-Tier



보안성, 확장성, 안정성
Java 등과 경쟁하려면
프레임워크화와 병행하면 추가 부하는 크지 않다
32