BizWorks_Framework
Download
Report
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