C 3tier
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

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


  • 603 Views
  • Uploaded on
  • Presentation posted in: General

델파이 /C++ 빌더 3tier 프레임워크 기반 업무 개발. Case Study : 3tier framework based business project with Delphi/C++Builder. 볼랜드포럼 / 박지훈 [email protected] 이 세션의 목적. 업무 프로젝트에서의 표준화 -> 프레임워크 왜 프레임워크화를 해야 하는가 Delphi/C++Builder vs. Java/.NET 경쟁 웹 개발 방식들과 경쟁하여 살아남으려면 어떻게 할까 Multi-tier 방식의 유용성과 구현 사례

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


C 3tier

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

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

볼랜드포럼 / 박지훈

[email protected]


C 3tier

이 세션의 목적

  • 업무 프로젝트에서의 표준화->프레임워크

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

  • Delphi/C++Builder vs. Java/.NET 경쟁

    • 웹 개발 방식들과 경쟁하여 살아남으려면 어떻게 할까

  • Multi-tier 방식의 유용성과 구현 사례

    • 어떤 경우에 Multi-tier가 유리하며 어떻게 구현할 것인가


C 3tier

업무 개발


C 3tier

업무 개발의 특성 - 1

  • 일반적인 업무 프로젝트의 2대 이슈

    • 실무자의 요구 파악

    • 업무 배분 / 일정 준수

  • 화면 단위 개발

    • 화면들간의 연계성 적음

    • 기술적 요구 스펙이 높지 않음 - 요구된 업무 로직 구현이 중요

    • 계약직, 초급 위주로 개발하는 경우도 잦음

  • PM/PL의 역할

    • 일정 관리, 작업 배분에 치중

    • 기술적 이슈, 표준, 통일성의 문제에는 소홀하기 쉬움


C 3tier

업무 개발의 특성 - 2

  • 업무 개발 프로젝트의 진행 경향

    • 단위 화면들 사이에 중복 코드가 많아짐

    • 담당 개발자들 각각의 구현 방법이 다양할 수 있음

      • 로직, 컴포넌트 선택, UI 디자인

      • 백엔드 데이터베이스 구조와의 연계 방법

        => 예상치 못한 버그/오동작의 가능성이 높아짐

        => 크로스 테스트/디버깅의 어려움

    • 실제 난이도에 비해 인수/인계 부하 증가

    • 요구가 변경되었을 때의 유연성이 낮음

  • 더 나은 방법은 없을까?


C 3tier

표준화 이슈

  • 표준 수립의 효과

    • 공통 코드 제거/최소화 ⇒ 코딩 및 코드 관리 시간이 줄어듦

    • 공통 기술적 이슈 통합 관리 ⇒ 개발자들이 각각 시간을 소모하지 않도록

    • 크로스 테스트, 인수인계 용이

  • 표준화의 주요 대상

    • 공통 루틴 라이브러리, 허용 라이브러리/컴포넌트

    • Naming Convention

      • Hungarian? Prefix? Underscore? Camel Case? Pascal Case?

    • 공통 Data Access 방법

    • 메인 App <-> 화면 사이의 interface

    • 코딩 기법의 제어 - 델파이/C++의 과도한 자유도는 생산성 저하 요인

  • 테크니컬 아키텍트의 필요성

    • 트러블슈팅

      + 표준화 마스터 –개발 표준 수립/유지보수

      + Framework 개발, 유지보수


C 3tier

개발 표준의 프레임워크화

  • 공통 루틴 라이브러리의 한계

    • 개별 개발자들에게 사용을 강제하기 어렵다

    • 무분별한 공통 루틴 양산 - 관리의 어려움

  • 프레임워크화

    • 공통 화면 클래스(들)

    • 화면 객체의 표준 모듈화

      • exe(X) dll? bpl?

    • 공통 Data Access 방법

    • 공통 Main App 인터페이스 방법

    • 화면 프로젝트와 기본 멤버들의 자동 생성


C 3tier

경쟁


C 3tier

업무 개발 - 경쟁 1

  • 업무 개발 분야에서 언어/개발툴 동향

    • Java(J2EE) - 압도적 다수

    • .NET - 중/소규모 ASP.NET, 소수 (확산이 느림)

    • Delphi/C++Builder - 특화 분야 프로젝트

      • 실시간성이 필요한 프로젝트 - HTS 등

      • 하드웨어 인터페이스가 중요한 프로젝트 - ITS 등

      • 역동적인 UI가 필요한 프로젝트

  • 업무 개발과 Web

    • Java와 Web은 동반 성장해옴

    • Java가 환영 받는 이유?

      • Java는 방법론/프레임워크 표준화와 함께 발전해옴

      • 통상적 업무 개발에 적합 - 시스템 접근성을 거세 => 일정 예측성

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


C 3tier

업무 개발 –경쟁 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 - 서비스의 안정성, 확장성, 신뢰성


X internet 1

X Internet 사례 – 1. 로그인


X internet 2

X Internet 사례 – 2. 실행화면


X internet 3

X Internet 사례 – 3. 개발툴


X internet 4

X Internet 사례 – 4. 스크립트


C 3tier

프레임워크 구현


C 3tier

프레임워크 구현 - 1

  • 커스텀 폼 class (vs. TForm / TFrame)

    • 업무 프로젝트에 맞게 property, event 추가 및 제거

    • 기술적 이슈

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

    • 커스텀 폼을 IDE에 등록하여 해결

      • RegisterCustomModule()


C 3tier

(계속)

  • 커스텀 폼 클래스 구현

    TBizForm = class(TCustomForm)

    protected

    (기존 동작 override)

    public

    (메소드 추가)

    published

    (property 추가)

    (event 추가)

    end;

  • IDE에 커스텀 폼 클래스 등록

    RegisterCustomModule(TBizForm, TCustomModule);

  • 메인 App에서 클래스 등록

    RegisterClass (TCF5211);


C 3tier

프레임워크 구현 - 2

  • 화면 프로젝트 - 패키지(bpl) (dynamic loading)

    • 메인 App과의 인터페이스 자유로움

    • IDE 자체와도 자유롭게 연동 (디자인타임에도 동작)

    • 디자인타임 컴포넌트화도 가능

    • bpl 로드 - LoadPackage(Path);

  • 커스텀 폼을 로드할 경우 클래스 타입을 인식하지 못한다

    • (무슨 폼 클래스).Create ?

    • 화면 bpl 쪽 - RegisterClass() 호출로 클래스 등록

    • 메인 App 쪽 - FindClass()로 클래스를 얻은 후 폼 생성


C 3tier

(계속)

화면 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;


C 3tier

프레임워크 구현 - 3

  • 폼/프로젝트 Wizard

    • IDE에서 자동으로 업무용 커스텀 폼/프로젝트를 생성

    • 개발자가 중요하지 않은 문제에 집중하지 않도록 한다

      공통 함수, 공통 추가 컴포넌트, 공통 property 값 등

    • Uses ToolsAPI

    • Wizard/Creator 인터페이스 구현 클래스 작성

    • Wizard

      • IOTAFormWizard, IOTAProjectWizard, IOTARepositoryWizard

    • Creator

      • IOTAProjectCreator, IOTAModuleCreator

    • 화면 프로젝트 기본 설정들 미리 적용

      • lib dir, output dir, run param, version info ...


C 3tier

프레임워크 구현 - 4

  • Core 인터페이싱 데이터모듈 bpl (static loading)

    • 메인 App (exe) -> 화면 bpl 인터페이스는 용이

    • 화면 bpl -> 메인 App (exe) 인터페이스는 곤란

    • 메인 App의 기능들 중 화면 bpl과 인터페이스가 필요한 기능은 중앙 bpl로 분리

      • DB connection, Access control ...

      • bpl 폼 로딩 및 관리 루틴


Multi tier

Multi-tier


Why multi tier

Why Multi-tier?

  • 소규모 환경에서의 성능은 이슈가 아님

    • 적은 유저, 적은 부하 환경에서는 2티어가 성능상 유리

      • 데이터는 티어 개수만큼의 경로를 거침

    • 고려사항 - DB 서버 부하 vs. 각 티어 데이터 전달 단계

  • 멀티티어의 장점

    • 보안성 - DB 서버 직접 액세스 차단, 암호화/보안 기능 추가 가능

    • 미들 서버의 존재 - DB 연결 풀링, 데이터 캐싱

    • 확장성 - 다수의 DB 서버, 다수의 미들 서버

    • 안정성/신뢰성 - Load Balancing, Fail Over

  • 멀티티어의 단점

    • 아키텍처가 복잡, 코드량 증가

    • 디버깅 난점


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. (다음 세미나엔…? ^^)


Delphi multi tier 2

Delphi Multi-tier 방법의 선택 - 2

  • TP Monitor 등 상용 미들웨어 제품

    • 고비용 - per 서버!

    • 패키지 판매 제품이므로 지원 기능 스펙에 제한

      • 다양한 서버쪽 추가 기능 구현 불가

      • Delphi 구현은 클라이언트에 국한

    • 금융기관, 대형병원 등에서 사용

  • 상용 Delphi 미들웨어 컴포넌트 라이브러리

    • 저비용 (수백 달러)

    • DataSnap보다 강력한 기능 / 높은 성능

    • 광범위한 기능 추가 가능

    • kbmMW, RemObjects, RealThinClient, MidWare, ASTA ...


Why kbmmw

Why kbmMW?

  • kbmMW의 장점

    • 기존 델파이 방식과 유사

    • 높은 성능 (kbmMemTable, 패킷 압축 등)

    • 무료 버전 존재, 소스 제공 (상용)

    • 다양한 외부 데이터 액세스 / 통신 / 암호화 컴포넌트 등을 지원

    • Java, C#, PHP와도 연동 가능

    • 다양한 부가 기능

      • load balancing, file service, messaging 등

  • kbmMW의 단점

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

    • 소소한 버그가 약간 있다

    • 데이터 페이징이 안된다


Kbmmw

kbmMW 서버 메인

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

    • TkbmMWServer 컴포넌트

    • TkbmMWTCPIPIndyServerTransport 컴포넌트

      • 클라이언트와의 패킷 전송 담당

    • TkbmMWADOXConnectionPool 컴포넌트

      • DB 커넥션 풀링


Kbmmw1

kbmMW 서비스 객체

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

    • TkbmMWCustomService

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

    • TkbmMWQueryService

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


C 3tier

서비스측 컴포넌트

  • Resolver

  • TkbmMWServerQuery

  • TkbmMWServerStoredProc


C 3tier

클라이언트 화면 컴포넌트

  • TkbmMWClientQuery

  • TkbmMWClientStoredProc

  • TkbmMWClientTransactionResolver


Troubleshooting

Troubleshooting

  • bpl은 바이너리 의존성이 대단히 높다

    • dll과 달리 클래스 인터페이스이기 때문

    • 특히 Core 모듈 bpl

    • interface 섹션 (not implementation)

    • 주의! 전체 재컴파일을 해야 할 경우가 잦을 수 있음

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


C 3tier

정리

  • 프레임워크화

    • 표준화의 연장선상에서 진행 가능

    • 보다 효율적인 개발 진행

    • 업계의 트렌드 (C/S 툴이라고???)

  • Multi-Tier

    • 보안성, 확장성, 안정성

    • Java 등과 경쟁하려면

    • 프레임워크화와 병행하면 추가 부하는 크지 않다


  • Login