c 3tier
Download
Skip this Video
Download Presentation
델파이 /C++ 빌더 3tier 프레임워크 기반 업무 개발

Loading in 2 Seconds...

play fullscreen
1 / 32

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


  • 728 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' 델파이 /C++ 빌더 3tier 프레임워크 기반 업무 개발' - ferris-wheeler


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]

slide2
이 세션의 목적
  • 업무 프로젝트에서의 표준화->프레임워크
    • 왜 프레임워크화를 해야 하는가
  • Delphi/C++Builder vs. Java/.NET 경쟁
    • 웹 개발 방식들과 경쟁하여 살아남으려면 어떻게 할까
  • Multi-tier 방식의 유용성과 구현 사례
    • 어떤 경우에 Multi-tier가 유리하며 어떻게 구현할 것인가
slide4
업무 개발의 특성 - 1
  • 일반적인 업무 프로젝트의 2대 이슈
    • 실무자의 요구 파악
    • 업무 배분 / 일정 준수
  • 화면 단위 개발
    • 화면들간의 연계성 적음
    • 기술적 요구 스펙이 높지 않음 - 요구된 업무 로직 구현이 중요
    • 계약직, 초급 위주로 개발하는 경우도 잦음
  • PM/PL의 역할
    • 일정 관리, 작업 배분에 치중
    • 기술적 이슈, 표준, 통일성의 문제에는 소홀하기 쉬움
slide5
업무 개발의 특성 - 2
  • 업무 개발 프로젝트의 진행 경향
    • 단위 화면들 사이에 중복 코드가 많아짐
    • 담당 개발자들 각각의 구현 방법이 다양할 수 있음
      • 로직, 컴포넌트 선택, UI 디자인
      • 백엔드 데이터베이스 구조와의 연계 방법

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

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

    • 실제 난이도에 비해 인수/인계 부하 증가
    • 요구가 변경되었을 때의 유연성이 낮음
  • 더 나은 방법은 없을까?
slide6
표준화 이슈
  • 표준 수립의 효과
    • 공통 코드 제거/최소화 ⇒ 코딩 및 코드 관리 시간이 줄어듦
    • 공통 기술적 이슈 통합 관리 ⇒ 개발자들이 각각 시간을 소모하지 않도록
    • 크로스 테스트, 인수인계 용이
  • 표준화의 주요 대상
    • 공통 루틴 라이브러리, 허용 라이브러리/컴포넌트
    • Naming Convention
      • Hungarian? Prefix? Underscore? Camel Case? Pascal Case?
    • 공통 Data Access 방법
    • 메인 App <-> 화면 사이의 interface
    • 코딩 기법의 제어 - 델파이/C++의 과도한 자유도는 생산성 저하 요인
  • 테크니컬 아키텍트의 필요성
    • 트러블슈팅

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

+ Framework 개발, 유지보수

slide7
개발 표준의 프레임워크화
  • 공통 루틴 라이브러리의 한계
    • 개별 개발자들에게 사용을 강제하기 어렵다
    • 무분별한 공통 루틴 양산 - 관리의 어려움
  • 프레임워크화
    • 공통 화면 클래스(들)
    • 화면 객체의 표준 모듈화
      • exe(X) dll? bpl?
    • 공통 Data Access 방법
    • 공통 Main App 인터페이스 방법
    • 화면 프로젝트와 기본 멤버들의 자동 생성
slide9
업무 개발 - 경쟁 1
  • 업무 개발 분야에서 언어/개발툴 동향
    • Java(J2EE) - 압도적 다수
    • .NET - 중/소규모 ASP.NET, 소수 (확산이 느림)
    • Delphi/C++Builder - 특화 분야 프로젝트
      • 실시간성이 필요한 프로젝트 - HTS 등
      • 하드웨어 인터페이스가 중요한 프로젝트 - ITS 등
      • 역동적인 UI가 필요한 프로젝트
  • 업무 개발과 Web
    • Java와 Web은 동반 성장해옴
    • Java가 환영 받는 이유?
      • Java는 방법론/프레임워크 표준화와 함께 발전해옴
      • 통상적 업무 개발에 적합 - 시스템 접근성을 거세 => 일정 예측성

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

slide10
업무 개발 –경쟁 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 - 서비스의 안정성, 확장성, 신뢰성
slide16
프레임워크 구현 - 1
  • 커스텀 폼 class (vs. TForm / TFrame)
    • 업무 프로젝트에 맞게 property, event 추가 및 제거
    • 기술적 이슈
      • 디자인타임 Object Inspector에 property가 나타나지 않음
    • 커스텀 폼을 IDE에 등록하여 해결
      • RegisterCustomModule()
slide17
(계속)
  • 커스텀 폼 클래스 구현

TBizForm = class(TCustomForm)

protected

(기존 동작 override)

public

(메소드 추가)

published

(property 추가)

(event 추가)

end;

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

RegisterCustomModule(TBizForm, TCustomModule);

  • 메인 App에서 클래스 등록

RegisterClass (TCF5211);

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

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

slide20
프레임워크 구현 - 3
  • 폼/프로젝트 Wizard
    • IDE에서 자동으로 업무용 커스텀 폼/프로젝트를 생성
    • 개발자가 중요하지 않은 문제에 집중하지 않도록 한다

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

    • Uses ToolsAPI
    • Wizard/Creator 인터페이스 구현 클래스 작성
    • Wizard
      • IOTAFormWizard, IOTAProjectWizard, IOTARepositoryWizard
    • Creator
      • IOTAProjectCreator, IOTAModuleCreator
    • 화면 프로젝트 기본 설정들 미리 적용
      • lib dir, output dir, run param, version info ...
slide21
프레임워크 구현 - 4
  • Core 인터페이싱 데이터모듈 bpl (static loading)
    • 메인 App (exe) -> 화면 bpl 인터페이스는 용이
    • 화면 bpl -> 메인 App (exe) 인터페이스는 곤란
    • 메인 App의 기능들 중 화면 bpl과 인터페이스가 필요한 기능은 중앙 bpl로 분리
      • DB connection, Access control ...
      • bpl 폼 로딩 및 관리 루틴
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 컨테이너 모듈
slide29
서비스측 컴포넌트
  • Resolver
  • TkbmMWServerQuery
  • TkbmMWServerStoredProc
slide30
클라이언트 화면 컴포넌트
  • TkbmMWClientQuery
  • TkbmMWClientStoredProc
  • TkbmMWClientTransactionResolver
troubleshooting
Troubleshooting
  • bpl은 바이너리 의존성이 대단히 높다
    • dll과 달리 클래스 인터페이스이기 때문
    • 특히 Core 모듈 bpl
    • interface 섹션 (not implementation)
    • 주의! 전체 재컴파일을 해야 할 경우가 잦을 수 있음

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

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