winkey.tistory.com · Web view[그림 21] 팀 개발 프로세스와 구성원, 서버 개발 팀...

2005. 10

.NET 개발 표준 가이드는 Microsoft 고객들을 위해 배포되었습니다. 본 문서는 상업적

목적으로 재 활용될 수 없으며, 기업 내부에서 사용할 목적으로는 자유롭게 수정, 보완하실 수 있습니다. .NET 개발 표준 가이드 문서에 대한 모든 권리는

마이크로소프트(유)에 있으며, 이 개발 표준 가이드에 대한 기술지원은 제공되지

않습니다.

.NET 개발 표준 가이드

.NET 개발 표준 가이드 개발 전 – 계획 과 준비

목차목차.............................................................................................................................................. 21. 소개....................................................................................................................................... 6

1.1. 개발 가이드 소개........................................................................................................61.1.1. 이 문서의 목적.....................................................................................................61.1.2. 이 문서를 읽어야 할 대상......................................................................................61.1.3. 전체적인 구성......................................................................................................6

1.2. .NET 프로젝트 Life Cycle...........................................................................................61.2.1. .NET 프로젝트 Life Cycle 개요.............................................................................61.2.2. 개요 – 개발 전.....................................................................................................61.2.3. 개요 – 개발 중.....................................................................................................61.2.4. 개요 – 개발 후.....................................................................................................6

2. 개발 전 – 계획과 준비...............................................................................................................62.1. 플랫폼 선정...............................................................................................................6

2.1.1. .NET 플랫폼의 장점.............................................................................................62.1.1.1. 단일 프로그래밍 모델.....................................................................................62.1.1.2. 다양한 프로그래밍 언어 지원..........................................................................62.1.1.3. 신뢰성, 확장성, 성능, 보안..............................................................................62.1.1.4. 저비용, 고효율..............................................................................................62.1.1.5. 웹 서비스를 위한 플랫폼.................................................................................6

2.1.2. 애플리케이션 구현 형태 결정.................................................................................62.1.2.1. 웹 애플리케이션............................................................................................62.1.2.2. Windows Form 애플리케이션 (C/S)................................................................62.1.2.3. 스마트 클라이언트.........................................................................................62.1.2.4. 애플리케이션 형태 Matrix..............................................................................6

2.1.3. 분산 애플리케이션 구현 시....................................................................................62.1.3.1. COM+ 사용 여부..........................................................................................62.1.3.2. .NET Remoting vs. 웹 서비스........................................................................6

2.1.3.2.1. .NET Remoting..............................................................................62.1.3.2.2. 웹 서비스........................................................................................6

2.2. 애플리케이션 아키텍처 디자인.....................................................................................62.2.1. 개요...................................................................................................................6

2.2.1.1. 애플리케이션 아키텍처란?..............................................................................62.2.1.2. 계층 분할의 장단점........................................................................................62.2.1.3. 논리적 아키텍처와 물리적 아키텍처.................................................................6

2.2.2. 논리적 아키텍처 디자인........................................................................................6

2


2.2.2.1. Presentation Layer.....................................................................................62.2.2.1.1. Thin 클라이언트 – 웹 애플리케이션....................................................62.2.2.1.2. Rich 클라이언트 – Windows 애플리케이션 기반..................................6

2.2.2.2. Business Logic Layer..................................................................................62.2.2.2.1. Business Façade Layer..................................................................62.2.2.2.2. Business Rule Layer......................................................................6

2.2.2.3. Data Access Layer......................................................................................62.2.2.3.1. Data Access Helper.......................................................................62.2.2.3.2. ADO.NET Data Provider.................................................................6

2.2.2.4. Data Source Layer......................................................................................62.2.2.5. 기타 Layer...................................................................................................6

2.2.3. 물리적 아키텍처 디자인........................................................................................62.2.3.1. 2-Tier..........................................................................................................62.2.3.2. 3-Tier..........................................................................................................62.2.3.3. N-Tier (Distributed 3-Tier)...........................................................................62.2.3.4. SOA(Service-Oriented Architecture)...........................................................6

2.2.4. N-Tier에서 서버 배치 모델....................................................................................62.2.4.1. Web Farm 모델............................................................................................6

2.2.4.1.1. InProcess 모델...............................................................................62.2.4.1.2. Out-Of-Process 모델 1....................................................................62.2.4.1.3. Out-Of-Process 모델 2....................................................................6

2.2.4.2. Dedicated 모델............................................................................................62.2.4.2.1. DCOM RPC를 사용..........................................................................62.2.4.2.2. .NET 리모팅을 사용..........................................................................62.2.4.2.3. XML 웹 서비스를 사용......................................................................6

2.2.5. .NET 관련 기술 정리............................................................................................62.3. 시스템 아키텍처 디자인...............................................................................................6

2.3.1. 네트워크 아키텍처...............................................................................................62.3.1.1. Intranet 아키텍처.........................................................................................62.3.1.2. Internet 아키텍처.........................................................................................6

2.3.2. 하드웨어 아키텍처...............................................................................................62.3.2.1. 데이터베이스 서버.........................................................................................62.3.2.2. 애플리케이션 서버.........................................................................................62.3.2.3. 웹 서버........................................................................................................62.3.2.4. 개발 서버.....................................................................................................62.3.2.5. 개발자 PC....................................................................................................6

2.3.3. 클러스터링, 로드밸런싱 관련 기술..........................................................................6

3


2.3.3.1. 클러스터링의 개념.........................................................................................62.3.3.2. Windows 2000 클러스터링 기술 개요.............................................................62.3.3.3. MSCS(Microsoft Cluster Service).................................................................62.3.3.4. CLB(Component Load Balancing)...............................................................62.3.3.5. NLB(Network Load Balancing)....................................................................6

2.4. 팀 개발 환경..............................................................................................................62.4.1. 팀 개발 모델........................................................................................................6

2.4.1.1. 팀 개발 개요.................................................................................................62.4.1.1.1. 팀 개발의 특징.................................................................................62.4.1.1.2. 팀 개발의 문제점..............................................................................62.4.1.1.3. 팀 개발 문제 해결을 위한 열쇠...........................................................62.4.1.1.4. 팀 개발 프로세스 – High Level Life Cycle.........................................6

2.4.1.2. 팀 개발 프로세스 구축 순서............................................................................62.4.1.2.1. 팀 개발 환경 구축.............................................................................62.4.1.2.2. 팀 개발 환경을 위한 전용 하드웨어 리소스..........................................62.4.1.2.3. 웹 개발 모델 선정.............................................................................62.4.1.2.4. 소스프로젝트 구조 수립....................................................................62.4.1.2.5. 빌드 프로세스 구축..........................................................................6

2.4.2. 소스세이프 사용 가이드........................................................................................62.4.2.1. 소스세이프 개요............................................................................................62.4.2.2. 소스세이프 서버 구성.....................................................................................6

2.4.2.2.1. 소스세이프 데이터베이스 생성...........................................................62.4.2.2.2. 소스세이프 사용자 추가....................................................................62.4.2.2.3. 공유 설정........................................................................................6

2.4.2.3. Visual Studio .NET에서 소스세이프 사용법.....................................................62.4.2.3.1. 소스세이프에 솔루션/프로젝트 추가....................................................62.4.2.3.2. 소스세이프에서 솔루션/프로젝트 가져오기..........................................62.4.2.3.3. 소스 제어 하에서 개발......................................................................62.4.2.3.4. 기타...............................................................................................6

2.4.2.4. Visual Studio .NET 2003에서 소스세이프 변경사항.........................................62.4.2.4.1. 소스제어 추가 시 ‘.root’가 붙게 됨.....................................................62.4.2.4.2. 임시 파일(~sak) 없애기...................................................................6

3. 개발 중 – 설계와 구현...............................................................................................................63.1. 분석 및 설계..............................................................................................................6

3.1.1. 설계 프로세스 개요..............................................................................................63.1.1.1. 설계 프로세스...............................................................................................63.1.1.2. 공정표.........................................................................................................6

4


3.1.2. Conceptual Design............................................................................................63.1.2.1. 수행 절차.....................................................................................................6

3.1.2.1.1. Conceptual Design Research.........................................................63.1.2.1.2. Conceptual Design Analysis..........................................................63.1.2.1.3. Conceptual Design Optimization...................................................6

3.1.2.2. 세부 행동 설명..............................................................................................63.1.2.2.1. Context.........................................................................................63.1.2.2.2. Workflow Process..........................................................................63.1.2.2.3. Use Case Scenario........................................................................6

3.1.2.3. 고려사항......................................................................................................63.1.3. Logical Design...................................................................................................6

3.1.3.1. 수행 절차.....................................................................................................63.1.3.1.1. Logical Design Analysis.................................................................63.1.3.1.2. Logical Design Rationalization.......................................................6

3.1.3.2. 세부 행동 설명..............................................................................................63.1.3.2.1. Object 추출 및 정의.........................................................................63.1.3.2.2. Object 상관도.................................................................................63.1.3.2.3. Service 일반화................................................................................63.1.3.2.4. Class Diagram (선택적으로 작업 수행).............................................63.1.3.2.5. UI Scratch (Sketch).......................................................................63.1.3.2.6. Logical ERD...................................................................................6

3.1.3.3. 고려사항......................................................................................................63.1.4. Physical Design.................................................................................................6

3.1.4.1. 수행 절차.....................................................................................................63.1.4.1.1. Physical Design Research..............................................................63.1.4.1.2. Physical Design Analysis...............................................................63.1.4.1.3. Physical Design Rationalization.....................................................63.1.4.1.4. Physical Design Specification Analysis..........................................6

3.1.4.2. 세부 행동 설명..............................................................................................63.1.4.2.1. Component 상관도.........................................................................63.1.4.2.2. Application 구조도..........................................................................63.1.4.2.3. Component 명세(Specification)......................................................63.1.4.2.4. UI 명세(Specification).....................................................................63.1.4.2.5. Physical ERD.................................................................................6

3.1.4.3. 고려사항......................................................................................................63.2. 구현 – 일반 지침.........................................................................................................6

3.2.1. 개발 환경 설정.....................................................................................................6

5


3.2.1.1. 개발 PC 설정................................................................................................63.2.1.2. 운영체제별 환경 설정.....................................................................................6

3.2.1.2.1. Windows 2000 / Windows XP Professional의 경우..........................63.2.1.2.2. Windows 2003의 경우....................................................................6

3.2.1.3. VS .NET 환경 설정........................................................................................63.2.1.3.1. 키보드 단축키 설정..........................................................................63.2.1.3.2. 탭과 들여쓰기 지정..........................................................................63.2.1.3.3. 데이터베이스 연결 설정....................................................................6

3.2.2. 프로젝트 생성 및 구조 수립...................................................................................63.2.2.1. 개요.............................................................................................................63.2.2.2. 프로젝트 계층 구조 수립 방식의 종류...............................................................63.2.2.3. 소스 프로젝트 구조 기획.................................................................................63.2.2.4. 실제 프로젝트 생성........................................................................................6

3.2.2.4.1. 솔루션 생성.....................................................................................63.2.2.4.2. 마스터 프로젝트 템플릿 생성.............................................................63.2.2.4.3. 마스터 프로젝트 템플릿에 프로젝트 추가............................................63.2.2.4.4. 업무별 프로젝트 템플릿 생성.............................................................63.2.2.4.5. 업무별 프로젝트 템플릿에 프로젝트 추가............................................6

3.2.2.5. 프로젝트 구조 생성 결과.................................................................................63.2.3. 명명 규칙(Naming Rule)......................................................................................6

3.2.3.1. 일반 사항.....................................................................................................63.2.3.1.1. 대소문자 혼용..................................................................................63.2.3.1.2. 약어 사용을 자제..............................................................................63.2.3.1.3. 단어의 선정.....................................................................................6

3.2.3.2. 네임스페이스 명명 규칙..................................................................................63.2.3.3. 클래스 명명 규칙...........................................................................................63.2.3.4. 인터페이스 명명 규칙.....................................................................................63.2.3.5. 메서드 명명 규칙...........................................................................................63.2.3.6. 열거형(Enum) 명명 규칙...............................................................................63.2.3.7. 변수 및 필드 명명 규칙...................................................................................63.2.3.8. 상수(Constants) 명명 규칙............................................................................63.2.3.9. 속성(Property) 명명 규칙..............................................................................63.2.3.10. 이벤트 명명 규칙....................................................................................6

3.2.4. 주석 사용 지침.....................................................................................................63.2.4.1. 일반 사항.....................................................................................................63.2.4.2. C# 주석 포맷...............................................................................................6

3.2.4.2.1. 단일 라인 주석.................................................................................6

6


3.2.4.2.2. 블록 주석........................................................................................63.2.4.2.3. XML 주석........................................................................................6

3.2.4.3. 소스코드 주석 권장안.....................................................................................63.2.4.4. VB.net 주석 포맷..........................................................................................6

3.2.4.4.1. 단일 라인, 블록 주석........................................................................63.2.4.4.2. XML 주석........................................................................................6

3.2.4.5. 소스코드 주석 권장안.....................................................................................63.3. 구현 – 프로그래밍 지침...............................................................................................6

3.3.1. 개요...................................................................................................................63.3.2. 계층 간 데이터 전달.............................................................................................6

3.3.2.1. 별도의 메서드 매개변수로 전달.......................................................................63.3.2.2. Entity 클래스 / 구조체로 전달........................................................................63.3.2.3. 데이터 컨테이너 사용 - DataSet.....................................................................63.3.2.4. 데이터 컨테이너 사용 - DataPack...................................................................63.3.2.5. 권장 사항.....................................................................................................6

3.3.3. Presentation Layer 개발 지침..............................................................................63.3.3.1. ASP.NET Web Form.....................................................................................6

3.3.3.1.1. 웹 폼 클래스 계층 구조.....................................................................63.3.3.1.2. ASP.NET 서버 컨트롤의 활용.............................................................63.3.3.1.3. Fetch와 DataBind..........................................................................63.3.3.1.4. Load와 PreRender 이벤트...............................................................63.3.3.1.5. 구현 순서........................................................................................6

3.3.3.2. Windows Form............................................................................................63.3.3.2.1. Windows Form 클래스 계층 구조......................................................63.3.3.2.2. Windows Form 컨트롤의 활용..........................................................63.3.3.2.3. Fetch와 DataBind..........................................................................63.3.3.2.4. Windows Form의 이벤트.................................................................63.3.3.2.5. 구현 순서........................................................................................6

3.3.4. Business Façade Layer 개발 지침.......................................................................63.3.4.1. .NET Remoting............................................................................................63.3.4.2. 웹 서비스(Web Services)..............................................................................6

3.3.5. Business Rule Layer 개발 지침............................................................................63.3.5.1. RuleBase 클래스..........................................................................................63.3.5.2. 트랜잭션이 필요하지 않은 클래스(_NTx)..........................................................63.3.5.3. 트랜잭션이 필요한 클래스(_Tx).......................................................................6

3.3.6. Data Access Layer 개발 지침..............................................................................63.3.6.1. DacBase 클래스...........................................................................................6

7


3.3.6.2. DAC 클래스 작성...........................................................................................63.3.6.3. DAC 클래스 메서드 작성................................................................................6

3.3.6.3.1. 쿼리를 사용하는 경우.......................................................................63.3.6.3.2. 저장 프로시저를 사용하는 경우..........................................................6

3.3.7. Database Connection 관리.................................................................................63.3.7.1. 개요.............................................................................................................63.3.7.2. 연결 문자열(Connection String)....................................................................63.3.7.3. 연결 풀링(Connection Pooling).....................................................................63.3.7.4. 자동 Connection 관리...................................................................................6

3.3.8. 트랜잭션 처리......................................................................................................63.3.8.1. 개요.............................................................................................................63.3.8.2. 데이터베이스 트랜잭션...................................................................................63.3.8.3. ADO.NET 수동 트랜잭션................................................................................63.3.8.4. COM+ 수동 트랜잭션....................................................................................63.3.8.5. COM+ 자동 트랜잭션....................................................................................63.3.8.6. 트랜잭션 방법 비교........................................................................................63.3.8.7. DxFrameworkLite에서의 트랜잭션 관리.........................................................6

3.3.8.7.1. AutoComplete의 사용.....................................................................63.3.8.7.2. DxFrameworkLite에서 트랜잭션 구현...............................................6

3.3.8.8. 결론.............................................................................................................63.3.9. 예외 처리............................................................................................................6

3.3.9.1. 예외처리와 관련한 일반적 사항.......................................................................63.3.9.1.1. 예외처리 과정..................................................................................63.3.9.1.2. 예외 탐지........................................................................................63.3.9.1.3. 예외 전달........................................................................................6

3.3.9.2. 사용자 정의 예외...........................................................................................63.3.9.3. Unhandled Exception 관리..........................................................................6

3.3.9.3.1. Web.config....................................................................................63.3.9.3.2. @Page 지시자................................................................................63.3.9.3.3. Page_Error.....................................................................................63.3.9.3.4. Application_Error...........................................................................6

3.3.9.4. N Tier 개발 시 예외 처리 전략........................................................................63.3.9.4.1. 기본 개념........................................................................................63.3.9.4.2. Business Logic Layer의 예외 처리...................................................63.3.9.4.3. Presentation Layer에서의 예외처리.................................................63.3.9.4.4. Unhandled Exception의 처리..........................................................6

3.3.9.5. 예외 정보 수집 및 로그...................................................................................6

8


3.3.9.5.1. 예외 정보 수집.................................................................................63.3.9.5.2. 로그 기록........................................................................................6

3.3.10. ASP.NET 상태 정보 관리.......................................................................................63.3.10.1. 개요......................................................................................................63.3.10.2. Cookie..................................................................................................6

3.3.10.2.1. 사용법............................................................................................63.3.10.2.2. 고려사항.........................................................................................6

3.3.10.3. ViewState............................................................................................63.3.10.3.1. 사용법............................................................................................63.3.10.3.2. 고려사항.........................................................................................6

3.3.10.4. Application...........................................................................................63.3.10.4.1. 사용법............................................................................................63.3.10.4.2. 고려사항.........................................................................................6

3.3.10.5. Session................................................................................................63.3.10.5.1. 사용법............................................................................................63.3.10.5.2. 고려사항.........................................................................................6

3.3.10.6. Cache..................................................................................................63.3.10.6.1. 사용법............................................................................................63.3.10.6.2. 고려사항.........................................................................................6

3.3.11. 구성 정보 파일 처리.............................................................................................63.3.11.1. 구성 파일의 유형....................................................................................6

3.3.11.1.1. 컴퓨터 구성 파일..............................................................................63.3.11.1.2. 보안 구성 파일.................................................................................63.3.11.1.3. 애플리케이션 구성 파일....................................................................6

3.3.11.2. 기본 구성 정보 섹션 사용법......................................................................63.3.11.3. 사용자 지정 섹션 사용법..........................................................................6

3.3.11.3.1. <configSections> 섹션..................................................................63.3.11.3.2. <DxFrameworkLite> 섹션..............................................................63.3.11.3.3. DxApplication 섹션.........................................................................6

3.3.12. 애플리케이션 보안 – 인증 및 권한 부여...................................................................63.3.12.1. 인증......................................................................................................6

3.3.12.1.1. ASP.NET 인증.................................................................................63.3.12.2. 권한 부여...............................................................................................6

3.3.12.2.1. 사용자 지정 권한 부여......................................................................63.3.12.2.2. 역할 기반 보안.................................................................................63.3.12.2.3. ASP.NET 권한 부여..........................................................................6

3.4. 테스트.......................................................................................................................6

9


3.4.1. 기능 테스트.........................................................................................................63.4.1.1. 개요.............................................................................................................63.4.1.2. 단위 테스트..................................................................................................6

3.4.1.2.1. NUnit 소개......................................................................................63.4.1.2.2. 테스트 코드 작성..............................................................................63.4.1.2.3. 테스트 수행.....................................................................................6

3.4.1.3. 사용자 액션 테스트........................................................................................63.4.2. 성능 및 부하 테스트.............................................................................................6

3.4.2.1. 개요.............................................................................................................63.4.2.2. ACT를 사용한 테스트.....................................................................................6

3.4.2.2.1. ACT 실행........................................................................................63.4.2.2.2. 테스트 프로젝트 생성.......................................................................63.4.2.2.3. 사용자 생성.....................................................................................63.4.2.2.4. 테스트 생성.....................................................................................63.4.2.2.5. 테스트 스크립트 사용자 정의.............................................................63.4.2.2.6. 테스트 실행.....................................................................................63.4.2.2.7. 결과 분석........................................................................................6

4. 개발 후 – 배포와 관리...............................................................................................................64.1. 배포..........................................................................................................................6

4.1.1. 배포 단계............................................................................................................64.1.1.1. 물리적 환경 상의 흐름....................................................................................64.1.1.2. 과정 상의 흐름..............................................................................................6

4.1.2. 배포 계획 수립.....................................................................................................64.1.2.1. 배포 내용 선정..............................................................................................6

4.1.2.1.1. 파일 및 폴더....................................................................................64.1.2.1.2. 어셈블리(Assembly).......................................................................64.1.2.1.3. Serviced Component(COM+ 컴포넌트)...........................................64.1.2.1.4. IIS 설정..........................................................................................64.1.2.1.5. 레지스트리 설정...............................................................................6

4.1.2.2. 배포 대상 선정..............................................................................................64.1.2.2.1. 클라이언트......................................................................................64.1.2.2.2. 웹 서버...........................................................................................64.1.2.2.3. 애플리케이션 서버...........................................................................64.1.2.2.4. 데이터베이스...................................................................................6

4.1.2.3. .NET Framework의 배포...............................................................................64.1.2.3.1. 사전 설치........................................................................................64.1.2.3.2. 애플리케이션과 함께 설치.................................................................6

10


4.1.2.4. 배포 전략 선정..............................................................................................64.1.2.4.1. 설치 패키지를 통한 배포...................................................................64.1.2.4.2. No-Touch 배포................................................................................64.1.2.4.3. 파일 복사........................................................................................6

4.1.3. 배포 전략 구현.....................................................................................................64.1.3.1. 설치 패키지..................................................................................................6

4.1.3.1.1. 설치 프로젝트 생성..........................................................................64.1.3.1.2. 파일 시스템 설정..............................................................................64.1.3.1.3. 시작 조건 지정.................................................................................64.1.3.1.4. 레지스트리에 추가...........................................................................64.1.3.1.5. 파일 형식 설정.................................................................................64.1.3.1.6. 사용자 지정 작업..............................................................................64.1.3.1.7. 사용자 인터페이스...........................................................................64.1.3.1.8. 설치 패키지 빌드..............................................................................6

4.1.3.2. No-Touch 배포.............................................................................................64.1.3.2.1. 웹 서버에 배포.................................................................................64.1.3.2.2. 클라이언트에서의 실행.....................................................................64.1.3.2.3. 보안 문제........................................................................................64.1.3.2.4. HTTP 를 통한 어플리케이션의 구동....................................................6

4.1.3.3. 파일 복사.....................................................................................................64.1.4. 유지 보수............................................................................................................6

4.1.4.1. 유지 보수 전략 수립.......................................................................................64.1.4.1.1. 업그레이드 레벨...............................................................................64.1.4.1.2. 업그레이드 선택 사항.......................................................................6

4.1.4.2. 버전 관리.....................................................................................................64.2. 운영 및 관리..............................................................................................................6

4.2.1. 시스템 관리.........................................................................................................64.2.1.1. 인터넷 정보 서비스........................................................................................64.2.1.2. 구성 요소 서비스...........................................................................................6

4.2.2. 모니터링.............................................................................................................64.2.2.1. 이벤트 로그..................................................................................................64.2.2.2. 작업 관리자..................................................................................................64.2.2.3. 성능 모니터..................................................................................................6

11


1. 소개

1.1. 개발 가이드 소개

이 장에서는 본 문서의 목적과 대상, 전체적인 구성에 대해서 설명한다.

1.1.1. 이 문서의 목적

이 문서의 목적은 .NET 애플리케이션 개발 프로젝트를 진행 시에 어떻게 계획을 수립하고, 프로젝트를 진행해 나갈 것이며, 실제 구현, 배포, 관리 시에 따라야 하는 지침을 제공하는

것이다. 각 단계에 대해 .NET 개발 표준 지침을 제공함으로써, 장차 개발될 .NET 프로젝트에

일관성과 규격을 제공한다.

1.1.2. 이 문서를 읽어야 할 대상

.NET 프로젝트를 진행 시에 이 문서를 반드시 읽어야 할 대상은 다음과 같다.역할 주요내용

프로젝트 관리자

(Project Manager)전체적인 .NET 프로젝트 Life Cycle을 이해

개발 전 계획 및 준비에 필요한 고려사항을 숙지

프로젝트 리더

(Project Leader)아키텍처 설계, 팀 개발환경 준비

구현 및 테스트 시 리드

개발자

(Developer)팀 개발 환경 하에서의 개발

구현 시 코딩 가이드라인 준수

테스터(Tester) 개발된 애플리케이션 테스트 시 고려사항

테스트 도구 활용법

1.1.3. 전체적인 구성

이 문서는 1장을 제외한 나머지 3개의 장으로 구성되어 있으며, 각각 개발 전, 개발 중, 개발 후에

관한 내용을 다루고 있다. 이러한 구성에 대해 보다 자세한 사항은 .NET 프로젝트 Life Cycle 을

참조하기 바란다.이 문서의 전체 내용을 읽을 시간이 없을 때에는, 이러한 구성을 감안하여 자신의 역할에 맞는

부분만을 선택해서 읽는 것을 권장한다.

12


1.2. .NET 프로젝트 Life Cycle

이 장에서는 일반적으로 .NET 애플리케이션을 개발할 때 일어나는 프로젝트 Life Cycle을

알아보고, 각 단계에서 어떠한 일들을 해야 하는가를 기술한다.

1.2.1. .NET 프로젝트 Life Cycle 개요

프로젝트는 크게 개발 전(개발을 위한 계획과 준비), 개발 중(애플리케이션을 실제로 구현), 개발

후(개발된 애플리케이션을 실제 환경에 적용)의 3단계로 나누어서 볼 수 있다. 다음 그림에서는

각 단계와 세부 프로세스, 프로세스 담당 역할을 보여주고 있다.

[그림 1] .NET 프로젝트 Life Cycle

이 프로젝트 Life Cycle은 대부분의 프로젝트에서 볼 수 있는 일반적인 것이며, 상황에 따라서

특정 프로세스는 생략될 수도 있다. 또한 구성원의 역할 역시 상황에 따라서는 한 명이 여러 개의

역할을 중복해서 가질 수도 있다.이제 각 단계에 대해서 간략하게 살펴보도록 하겠다.

1.2.2. 개요 – 개발 전

실제 애플리케이션 개발에 들어가기 전에 프로젝트 관리자(Project Manager)는 개발자들이

프로젝트를 원활하게 개발할 수 있도록 여러가지 준비를 해두어야 한다. 이 단계는 원칙적으로는

프로젝트 관리자의 역할이지만, 상황에 따라서 일부 내용은 프로젝트 리더(Project Leader)가

대행할 수 있다.플랫폼 선정 단계에서는 .NET 플랫폼이 적합한 상황인지를 판단해 보고, 애플리케이션을

어떠한 형태로 개발할 것인지를 결정하게 된다. 또한 .NET에서 제공하고 있는 관련 기술들이

13

Project Manager Business Modeler

Developer Tester System Admin

팀 개발 환경 구축

아키텍처 디자인

플랫폼 선정

개발 전 개발 중 개발 후

분석, 설계 배포

구현

테스트

관리, 모니터링


어떠한 것이 있는지를 파악해 본다.아키텍처 디자인 단계에서는 애플리케이션을 개발 및 실제 환경 시에 적용할 네트워크,

하드웨어, 소프트웨어 아키텍처를 결정하게 된다. 이 단계는 애플리케이션 개발 시에 매우 큰

영향을 미치므로, 다양한 요인을 가정하여 충분히 되어야 한다.팀 개발 환경 구축 단계에서는 엔터프라이즈 애플리케이션을 다수의 인원이 공동 개발할

때에 팀의 구성, 팀 개발 시 주의사항, 팀 개발 지원 소프트웨어에 대해서 알아본다.

1.2.3. 개요 – 개발 중

프로젝트 관리자는 개발 전 단계에서 계획하고 준비된 내용을 바탕으로 개발이 진행되고

있는지를 점검 및 확인해야 한다. 이 단계는 다양한 역할을 가진 구성원들이 공동 작업을 하게

되므로, 구성원들 간의 의사소통 및 협력이 매우 중요하다.분석, 설계 단계에서는 요구사항 및 업무 프로세스를 분석하여 구현해야 할 기능 사양을

정의하고, 이를 바탕으로 구현해야 할 내용을 모델링하게 된다. 이것은 비즈니스 모델러

(Business Modeler)가 수행해야 업무이지만, 별도로 할당된 모델러가 없는 경우에는 실제

구현할 개발자가 담당하는 경우도 있다. 프로젝트 관리자는 모델러(또는 개발자)들에게 분석, 설계해야 할 내용을 적절히 분배해야 한다.

구현 단계에서는 계획된 아키텍처와 모델링된 내용을 바탕으로 개발자가 실제 코드를

작성한다. 이 때 일관된 코딩 가이드라인을 준수하여 코드가 일정 수준 이상의 품질을 가지며, 규격화된 모습을 가지게 하는 것이 바람직하다.

테스트 단계에서는 작성된 애플리케이션의 기능 및 성능을 검증해 보게 된다. 이 단계에

시간을 많이 투자할수록 애플리케이션의 품질을 향상시킬 수 있다. 테스터(Tester)는 작업을 수행

후 결과를 프로젝트 관리자 및 개발자에게 피드백(Feedback)하여 문제점을 개선하고 수정할 수

있도록 해야 한다. 별도로 테스터가 존재하지 않는 경우에는 개발자가 대신 수행할 수도 있다.

1.2.4. 개요 – 개발 후

애플리케이션 개발이 완료되면 이를 실제 환경에 적용시키고, 유지 보수 및 관리를 하기 위한

계획과 지침을 수립해야 한다.배포 단계는 완성된 애플리케이션을 실제 환경에서 운용되는 서버로 올리거나, 일반

사용자들에게 설치할 수 있도록 설치패키지를 제공하는 것을 의미한다. 서버 애플리케이션의

경우, 개발 환경과 실제 환경의 차이점을 파악하고 필요한 환경 구성을 할 수 있도록 지침을

제공해야 한다. 클라이언트 애플리케이션의 경우, 일반 사용자들이 용이하게 설치할 수 있도록

다양한 PC 환경을 고려하여, 편리한 설치 인터페이스를 제공해야 한다.관리, 모니터링 단계는 배포된 애플리케이션을 효율적으로 관리하고, 다양한 요인들을 통해

애플리케이션을 모니터링 한 후 애플리케이션을 언제, 어떻게 확장할 것인지를 결정하는

단계이다. 시스템 관리자는 이 단계의 내용을 숙지해야 한다.

14


2. 개발 전 – 계획과 준비

2.1. 플랫폼 선정

애플리케이션 개발을 위해서는 어떤 플랫폼에서 어떠한 형태로 구현할 것인지를 사전에 고려해야

한다. 이 장에서는 .NET 플랫폼이 제공하는 장점으로 어떠한 것이 있으며, 웹 애플리케이션과

Windows 애플리케이션 중에 어떠한 것을 구현해야 하는지를 알아보게 된다. 또한 분산

애플리케이션 구현 시 COM+ 사용 여부, .NET Remoting과 웹 서비스 간에 어떤 것을 선택하는

것이 바람직한지를 알아보게 된다.

2.1.1. .NET 플랫폼의 장점

.NET 플랫폼이 제공하는 장점에는 여러가지가 있지만, 대표적인 내용만을 들도록 하겠다. 보다

자세한 사항은 Microsoft 웹 사이트를 참조하기 바란다.

2.1.1.1. 단일 프로그래밍 모델

과거에는 프로그래밍 언어를 어떠한 것을 선택하느냐 따라 개발하는 프로그래밍 모델이 크게

달라졌다. 프로그래밍 언어와 프로그래밍 모델이 종속됨으로써 언어를 변경하면 프로그래밍

모델도 변경됨으로써 유지 보수나 재개발의 범위가 커지게 되는 문제가 발생했다..NET은 계층 구조화된 프레임워크를 통해 단일한 프로그래밍 모델을 제시한다.

2.1.1.2. 다양한 프로그래밍 언어 지원

현재 .NET을 지원하는 언어는 20가지 이상이며, 서로 다른 언어를 사용해서 작성하더라도

이들을 통합해서 사용하는데는 아무런 문제가 없다. .NET은 플랫폼 독립성 뿐만 아니라 특정

언어에 종속되지 않는다.

2.1.1.3. 신뢰성, 확장성, 성능, 보안

기존 Win32 플랫폼에 비해 더욱 신뢰성 있고, 확장성이 뛰어나며, 좋은 성능과 높은 보안성을

제공한다.

2.1.1.4. 저비용, 고효율

.NET은 별도의 WAS가 필요없이 Windows 2000 이상의 시스템에서 웹 애플리케이션을 구동할

수 있으므로, 소프트웨어 개발 비용을 크게 절감한다. 또한 비용 대비 성능에서 타 플랫폼에 비해

탁월한 것으로 입증되었다.

15


또한 Visaul Studio .NET과 같은 막강한 개발도구를 통해 높은 개발생산성을 보장한다.

2.1.1.5. 웹 서비스를 위한 플랫폼

.NET은 애초부터 웹 서비스를 위한 플랫폼으로 디자인 되어, 웹 서비스를 가장 쉽고 강력하게

만들 수 있게 해준다. .NET 내부에는 웹 서비스를 작성 및 사용하는데 필요한 모든 요소들이 이미

포함되어 있다.

2.1.2. 애플리케이션 구현 형태 결정

애플리케이션을 어떠한 형태로 구현할 것인지는 초기에 결정되어야 할 요소 중 하나이다. .NET에서 구현 가능한 애플리케이션의 형태는 크게 3가지로 나누어 볼 수 있다.

ASP.NET 웹 애플리케이션

Windows Form 애플리케이션 (Client / Server) 스마트 클라이언트 (Smart Client) 각각의 장단점은 어떠하며, 언제 어느 것을 선택하는 것이 바람직한지를 살펴 보도록 하자.

2.1.2.1. 웹 애플리케이션

.NET에서의 웹 애플리케이션은 ASP.NET으로 구현되며, 클라이언트는 웹 브라우저를 통해서

애플리케이션에 접근하게 된다. 그러므로 자연히 웹 서버가 요구되게 된다.웹 애플리케이션의 장점은 클라이언트 컴퓨터에 별다른 설치가 필요없으며, 언제 어디서나

인터넷 접속이 가능하면 애플리케이션에 접근 가능하다는 것이다. 또한 서버 쪽만 변경해주면

되므로 애플리케이션 유지 보수가 매우 쉽다.웹 애플리케이션의 단점은 풍부한 기능과 UI를 제공하지 못한다는 한계점이 있다는 것이다.그러므로, 불특정 다수의 사용자(특히 외부 사용자)를 대상으로 하는 애플리케이션의 경우 웹

애플리케이션으로 구현되는 것이 바람직하며, 복잡한 UI를 필요로 하는 업무용 애플리케이션에는

다소 적합하지 않다.

2.1.2.2. Windows Form 애플리케이션 (C/S)

클라이언트 컴퓨터에 설치되는 Windows 애플리케이션을 의미한다. 클라이언트 애플리케이션은

서버 쪽에 있는 요소와 연동하여 작업을 수행하게 된다.Windows Form 애플리케이션의 장점은 Windows가 제공하는 풍부한 UI와 기능을 활용할 수

있으며, 기존의 3rd party 컴포넌트가 다양하다는데 있다.Windows Form 애플리케이션의 단점은 클라이언트 애플리케이션에 설치하는 과정과 서버에

연결하기 위한 연결 정보를 알고 있어야 한다는 것이다. 또한 애플리케이션 유지 보수 시 버전

관리나 배포 작업이 어렵다. 그리고 Windows Form 애플리케이션의 구동을 위해서는

16


클라이언트 컴퓨터에 .NET Framework가 설치되어야 한다.그러므로, Windows Form 애플리케이션은 정해진 사용자(주로 내부 사용자)를 대상으로

인트라넷 내에서 운영되는 업무용 애플리케이션에 적합하다.

2.1.2.3. 스마트 클라이언트

스마트 클라이언트(Smart Client)는 웹 애플리케이션의 배포 및 유지보수의 장점과 Windows Form 애플리케이션의 풍부한 UI 및 기능을 결합한 것으로, High-Fidelity Client라고 부르기도

한다. 스마트 클라이언트는 Windows Form 애플리케이션을 웹 서버에 올려놓는 것만으로

애플리케이션의 배포 및 버전관리가 가능하다.스마트 클라이언트 시나리오에서는 Windows Form과 마찬가지로 클라이언트 컴퓨터에 .NET Framework가 필요하며, 보안 정책을 어떻게 배포하고 관리할 것인지에 대해 고려해야 한다.

2.1.2.4. 애플리케이션 형태 Matrix

2.1.3. 분산 애플리케이션 구현 시

2.1.3.1. COM+ 사용 여부

분산 애플리케이션을 구현 시는 미들웨어(Middleware)를 사용할 것인지를 결정해야 한다. .NET과 가장 적합한 미들웨어는 Windows 2000 이상의 OS에 내장되어 있는 COM+이다.다중 계층으로 이루어진 환경이라고 해서 무조건 COM+를 사용해야 하는 것은 아니므로, 다음의

경우에 COM+를 사용하는 것을 권장한다. 2개 이상의 데이터 소스를 사용하는 경우

분산 트랜잭션이 필요한 경우

17

유지보수성

기능, UI

웹 애플리케이션

스마트 클라이언트

Windows Form


트랜잭션 구분을 클래스로, 트랜잭션 단위를 메서드로 격리화 할 수 있는 경우

DB 테이블에 대한 동기화 처리가 복잡한 경우

리소스 관리가 필요한 경우

무상태 컴포넌트(Stateless Component)로 디자인이 가능한 경우

2.1.3.2. .NET Remoting vs. 웹 서비스

원격 메서드를 호출할 때, 과거에는 DCOM을 사용했으나 .NET에서는 DCOM 대신에 .NET Remoting이나 웹 서비스를 사용하는 것을 권장한다. .NET Remoting과 웹 서비스 간의 선택에

대한 보다 자세한 자료는 다음을 참조한다.

ASP.NET Web Services or .NET Remoting: How to Choosehttp://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch16.asp

2.1.3.2.1. .NET Remoting

DCOM의 후계기술로 명확하고 간단한 아키텍처를 통해서 원격 메서드 호출을 가능하게 한다. 주고 받는 프로토콜을 HTTP와 TCP 중 하나로 선택할 수 있으며, 포맷도 Binary 포맷과 SOAP 중에서 선택할 수 있다(TCP-Binary 조합이 가장 성능이 뛰어나며, 통상 IIS를 Remoting 호스트로 사용하는 HTTP-Binary 조합을 가장 많이 사용한다)..NET Remoting은 .NET이 제공하는 기능을 완벽하게 활용할 수 있으므로, .NET-to-.NET 시나리오에서 가장 이상적이다. 동일 .NET 플랫폼 간(특히 인트라넷 환경)에는 .NET Remoting의 사용을 권장한다.대신 단점으로는 이기종 플랫폼에서 사용할 수 없다는 것이다. 물론 3rd Party 업체에서 제공하는

브리징(Bridging) 소프트웨어(예 : Ja.NET)을 사용하여 J2EE와 .NET Remoting 간에 통신을 할

수 있게 해주는 제품이 있으나, 별도의 비용이 발생된다.

2.1.3.2.2. 웹 서비스

웹 서비스는 HTTP 프로토콜에 기반한 SOAP 프로토콜을 사용하여 원격 호출을 수행한다.웹 서비스는 이기종 플랫폼 간의 연동을 가능하게 해주며, 분산 애플리케이션에서 사실상 업계의

표준이 되어가고 있는 기술이다.웹 서비스의 단점은 상대적으로 느린 속도와 .NET Remoting만큼 .NET 개체를 완벽하게

지원하지 못한다는데 있다.

2.2. 애플리케이션 아키텍처 디자인

아키텍처는 크게 애플리케이션 아키텍처(Application Architecture)와 시스템 아키텍처

18

http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch16.asp


(System Architecture)의 두 가지 종류로 나누어 볼 수 있다. 이 장에서는 애플리케이션

아키텍처를 어떻게 디자인할 것인가에 대해 알아본다.

2.2.1. 개요

2.2.1.1. 애플리케이션 아키텍처란?

애플리케이션 아키텍처는 전체적인 애플리케이션을 계층화된 구성요소의 상관관계로 이루어진

구조로 나누는 것을 의미한다. 즉, 하나의 애플리케이션을 여러 개의 계층으로 분할함으로써

애플리케이션을 보다 이해하기 쉽게 만든다. 또한 각 구성요소의 성격과 특성 및 기능을

구분하며, 이를 물리적으로 배치함으로써 분산(Distribution)의 효과를 얻을 수 있다.

2.2.1.2. 계층 분할의 장단점

애플리케이션 아키텍처 상에서 계층을 나눌 때, 얼마나 다양한 개수로 나눌 것인가는 충분히

고민되어야 할 사항 중 하나이다. 통상적으로 보다 많은 계층을 둘수록, 다음과 같은 장단점이

존재한다.장점

계층 구조는 시스템 확장 및 진화가 용이하다. Layer를 격리하여, 애플리케이션의 변경을 최소화할 수 있다. 다른 Trust Domain 내에서 비즈니스 로직을 실행할 수 있다. C/S 모델에 비해 배포가 용이하다.단점

Tier를 많이 나눌수록 개발시간이 상대적으로 오래 걸린다. UI 단위가 아니라 컴포넌트 단위로의 분리가 필요하므로, CBD 기반의 개발방법론이

요구되는 경우가 많다. Tier 간 데이터를 전달할 때 여러가지 사항을 고려해야 한다. Tier 간 설계의 중요성이 상대적으로 크다. 분산 환경의 특성을 잘 알고 있는 숙련된 개발자를 요구한다. 새로운 프로그래머가 전체 구조를 이해하는데 시간이 오래 걸린다. Tier를 많이 거칠수록 속도가 저하된다.그러므로, 프로젝트 관리자나 아키텍트는 애플리케이션의 특성, 팀 구성원의 수준 등을 잘

고려하여 적절하게 계층을 나누어야 한다.

2.2.1.3. 논리적 아키텍처와 물리적 아키텍처

애플리케이션 아키텍처는 다시 논리적 아키텍처(Logical Architecture)와 물리적 아키텍처

19


(Physical Architecture)로 나누어 볼 수 있다.논리적 아키텍처는 애플리케이션을 각 계층에서 어떠한 기능과 역할을 수행하는가에 따라

논리적으로 분리한 것을 의미한다. 일반적으로 프리젠테이션 계층, 비즈니스 로직 계층, 데이터

액세스 계층 등으로 구분하곤 한다. 논리적 아키텍처 상에서의 계층은 레이어(Layer)라는 표현을

주로 사용한다.물리적 아키텍처는 논리적 계층(Layer)들을 실제 물리적으로 각 시스템에 어떻게 배치할

것인가를 의미한다. 물리적 아키텍처 상에서 계층은 티어(Tier)라는 표현을 주로 사용하며, 배치되는 구분에 따라 2-Tier, 3-Tier, N-Tier로 구분하곤 한다.논리적 아키텍처와 물리적 아키텍처는 따로 떼놓고 볼 수 없으며, 어떻게 디자인하는가에 따라서

서로 영향을 주는 경우가 많다. 물리적 아키텍처의 분산 정도는 논리적 아키텍처의 분산 정도보다

클 수가 없다. 또한 물리적 아키텍처를 변경하면, 논리적 아키텍처 상의 레이어들 간에 통신하는

방법이 변경될 수도 있다. 그래서 상당수 사람들은 논리적 아키텍처와 물리적 아키텍처를

혼용해서 생각하는 경우가 많으며, 레이어와 티어라는 단어도 거의 동일한 의미로 사용하는

경우가 많다(한글로는 둘 다 계층으로 번역하는 경우가 많다). 하지만 원칙상으로는 둘은 엄밀한

차이를 가지고 있다는 것에 주의해야 한다.논리적 아키텍처와 물리적 아키텍처의 분산 정도에 영향을 주는 요소들은 다음과 같다.

논리적 아키텍처 물리적 아키텍처

비즈니스 로직의 복잡도

개발 생산성

애플리케이션의 규모

개발자의 숙련도

계층 개발 모델(수평/수직)기타

가용한 서버의 대수

네트워크 설정

다른 애플리케이션 또는 다른 플랫폼과의 상호

운용(Interoperability)성능, 보안

기타

2.2.2. 논리적 아키텍처 디자인

논리적 아키텍처를 몇 개의 계층(Layer)로 나눌 것인가를 결정하는 가장 중요한 요소는

애플리케이션의 규모와 비즈니스 로직의 복잡도이다. Layer를 많이 나눌수록 구현하는데 걸리는

시간이 오래 걸리므로, 소규모-단기간 애플리케이션에 Layer를 과중하게 나누면, 오히려 개발

생산성, 유지 보수 등을 저하시키는 원인이 된다.논리적 아키텍처는 기능과 역할에 따라서 나누는 것이므로, 일반적인 계층 구조가 존재한다. 물론, 어떤 계층은 애플리케이션의 규모 및 복잡도, 프로젝트의 상황에 따라서 생략할 수도 있다. 다음은 애플리케이션의 규모에 따른 일반적인 계층 구조를 나타낸 표이다.

소규모 중간규모 대규모

Presentation O O OBusiness Façade O

20


Business Rule O O OData Access O OData Source O O O

상황에 따라서는 규모가 크더라도 몇몇 계층은 생략해서 만든 후, 차후에 계층을 추가해서 만들

수도 있다. 특히 Business Façade 계층은 차후에 선택적으로 래퍼(Wrapper) 형태로 구현되는

경우가 많다.

2.2.2.1. Presentation Layer

Presentation Layer는 사용자에게 입/출력을 제공하는 인터페이스를 의미한다. 일반적으로

Presentation Layer의 구현 기술은 클라이언트가 Thin 클라이언트인지, Rich 클라이언트인지에

따라서 달라지게 된다.

2.2.2.1.1. Thin 클라이언트 – 웹 애플리케이션

Thin 클라이언트인 경우, 클라이언트 애플리케이션은 일반적으로 HTML을 기반으로 하는 웹

브라우저를 의미한다. 이를 위해 Presentation Layer는 웹 애플리케이션으로 작성되어야

하며, .NET에서는 ASP.NET을 통해 구현하며, 이를 구동하기 위해서는 IIS(Internet Information Server)가 필요하다.일반적으로 Presentation Layer는 다음과 같은 요소들로 구성된다.

ASP.NET 웹 폼 : *.aspx ASP.NET 웹 폼 코드 비하인드 : *aspx.cs (C#)/ *.aspx.vb(VB.NET) ASP.NET 사용자 정의 컨트롤(Web User Control, Pagelet) : *.ascx ASP.NET 사용자 지정 컨트롤(Web Custom Control, Server Control) 클라이언트 스크립트 및 기타 : <script> 블록, *.js, *.htc, *.css, 이미지 파일 등

3rd Party 컨트롤 : Chart, Grid, Report 등을 위한 ActiveX 또는 WinForm 컨트롤

21


[그림 2] ASP.NET 웹 애플리케이션의 Presentation Layer 구성 요소

웹 애플리케이션으로 개발 시에는 다음과 같은 요소들을 고려해야 한다. 상태 정보 관리는 어떻게 할 것인가? 불특정 사용자의 접근을 방지하기 위해 인증(Authentication), 권한(Authorization)을

어떻게 부여할 것인가? 웹 팜(Web Farm) 또는 웹 가든(Web Garden)을 사용할 계획이 있는가? HTML로 표현이 불가능한 요소를 사용할 필요가 있는가? 클라이언트 브라우저의 종류, 버전

2.2.2.1.2. Rich 클라이언트 – Windows 애플리케이션 기반

Rich 클라이언트는 애플리케이션을 사용하기 위해 클라이언트 머신에 전용 애플리케이션을

설치해서 사용하는 형태를 의미한다. Windows 환경에서는 Windows 애플리케이션으로

구현되며, Win32 기반 또는 .NET에서 Windows Form(WinForm) 기반으로 작성될 수 있다. WinForm 기반의 클라이언트를 사용하려면, 클라이언트 머신에 반드시 .NET Framework이

설치되어 있어야 한다.Rich 클라이언트를 선택했을 경우, 클라이언트 머신에 애플리케이션을 어떻게 배포하고, 버전

관리, 업데이트를 수행할 것인가가 매우 중요한 문제가 된다. 배포 방식은 설치 패키지를 통해

설치하는 방법과 웹을 통해 배포하는 스마트 클라이언트(Smart Client) 방식이 있다. 배포에

관한 보다 자세한 설명은 4장을 참조하도록 한다.Rich 클라이언트로 개발 시에는 다음과 같은 요소들을 고려해야 한다.

애플리케이션을 어떻게 배포할 것인가? 버전관리, 업데이트는 어떻게 수행할 것인가?

22


WinForm으로 개발했다면, 클라이언트에 .NET 프레임워크를 어떻게 설치할 것인가? 3rd Party 컨트롤을 사용할 경우, 라이센스 문제와 배포 문제

구성 정보 및 환경 설정(DB 연결, 원격 컴포넌트 호출 등)2.2.2.2. Business Logic Layer

Business Logic Layer는 Presentation Layer에서 받은 사용자의 요청이나 입력 내용을

비즈니스 로직에 따라서 처리한 후, 처리된 결과를 Presentation Layer로 반환하는 역할을

수행한다. 이 계층은 컴포넌트 또는 클래스 기반의 코드로 작성이 될 수도 있으며, 데이터베이스의 저장 프로시저(Stored Procedure, SP)로 구현될 수도 있다.최근에는 Business Logic Layer를 Business Façade Layer(비즈니스 외관 계층)과 Business Rule Layer(비즈니스 규칙 계층)으로 나누어서 보는 경향이 있다.

2.2.2.2.1. Business Façade Layer

이 계층은 내부 비즈니스 개체에 대해 일관된 인터페이스를 제공하기 위한 상위 래퍼로서의

역할을 수행한다. Business Façade에서 수행하는 역할은 일반적으로 다음과 같다. Presentation Layer로부터 요청을 받는다. 요청에 따라 필요한 경우에는 직접 Data Access Layer를 액세스 한다

요청을 Business Rule Layer로 전달한다. Business Rule Layer에서 Presentation Layer로 응답을 반환한다. Business Rule을 호출하는 동안 임시 상태를 유지한다.

그 외에 추가적으로 다음과 같은 역할 및 기능을 부여할 수 있다. COM+ 사용 시, 트랜잭션 옵션을 클래스 단위로만 지정할 수 있으므로 통상 Business Rule Layer의 클래스 이름 뒤에 _NTx(Not Supported), _RTx(Requried) 등의 네이밍을 통하여

클래스들의 성격을 구분하게 된다. 이 때, Business Façade 계층에서 Business Rule 클래스에

대한 Factory 클래스를 제공하여, 트랜잭션 사용 여부에 관계없이 단일한 이름의 클래스로

접근할 수 있도록 해줄 수 있다. 이 계층에 원격 액세스가 필요할 때, System.MarshalByRefObject로부터 상속받도록

구현하여 .NET 리모팅으로 노출하기 위한 래퍼로 활용할 수 있다. 이 계층에 원격 액세스가 필요할 때, 웹 서비스로 노출하기 위한 래퍼로 활용할 수 있다. 일반적으로 System이라는 접미사를 붙이는 것을 권장한다. (예: ProductSystem)

이 계층을 디자인할 때는 다음과 같은 요소들을 고려해야 한다. Business Façade로 묶을 Business Rule 클래스 선정

23


.NET 리모팅이나 웹 서비스를 사용한 노출 여부

.NET 리모팅이나 웹 서비스로 노출할 메서드

.NET 리모팅이나 웹 서비스 사용 시 보안, 인증 모델

2.2.2.2.2. Business Rule Layer

이 계층은 실제 업무를 실행하기 위한 로직을 구현한다. 과거에 2 Tier 형태에서는 이 부분을

데이터베이스 저장 프로시저로 구현했지만, 3 Tier 이상의 모델에서는 컴포넌트 또는 클래스

기반의 코드로 구현하는 것이 바람직하다. 이 계층에서 수행하는 역할은 일반적으로 다음과 같다. Business Façade로부터 요청을 받는다. 업무 로직에 따라 요청을 처리한다. Data Access Layer를 사용하여 데이터베이스에 액세스 하여 쿼리 결과 데이터를 보낸다. 처리 결과를 다시 Business Façade로 전달한다. 데이터베이스 사용 시 트랜잭션을 제어한다.

그 외에 추가적으로 다음과 같은 역할 및 기능을 부여할 수 있다. COM+ 사용 시 System.EnterpriseServices.ServicedComponent를 상속받아서

COM+ 컴포넌트로 구현한다. 트랜잭션의 사용 여부를 결정하기 위한 단위이다. COM+에서는 클래스 단위로 트랜잭션

옵션을 지정할 수 있으므로 통상적으로 이를 구분하기 위해 Supported 인 경우에는 _Tx, Required은 경우에는 _RTx라는 접미사를 클래스 이름에 붙인다

COM+는 분산 트랜잭션 코디네이터(DTC: Distributed Transaction Coordinator)를 사용하여

데이터베이스와의 트랜잭션을 수행한다. 트랜잭션의 사용 여부는 Business Rule Layer 중 어느

클래스의 메서드가 호출되었는지를 기준으로 하게 된다. 예를 들어, 트랜잭션 옵션이 Required인

클래스의 메서드가 호출되면, 트랜잭션이 시작되게 되며, 이후에 불리는 메서드 중 트랜잭션

옵션이 Supported또는 Required로 설정된 클래스에 속한 메서드는 트랜잭션에 참여하게 된다. 일반적이거나 공통적인 동작을 처리해주는 로직이 사전에 정의되어 있는 기반 클래스

(RuleBase)에서 상속을 받도록 구현되는 것이 좋다. 이 경우, 궁극적인 상속 관계는 MyClass -▶ RuleBase -▶ ServicedComponent가 된다.

이 계층을 디자인할 때는 다음과 같은 요소들을 고려해야 한다. COM+ 서비스 사용 여부

비즈니스 로직 구현

비즈니스 로직의 구현 위치 (코드 또는 SP)

24


트랜잭션 필요 시, 트랜잭션의 범위와 Commit/Rollback을 위한 규칙

COM+ 트랜잭션 사용 시, 트랜잭션이 필요한 메서드와 필요하지 않은 메서드로 구분하여

알맞은 트랜잭션 옵션을 가진 클래스로 나누어야 함

2.2.2.3. Data Access Layer

이 계층은 데이터베이스(또는 기타 데이터 서비스)에서 데이터를 가져오거나 내보내는 기능을

수행한다. .NET에서는 주로 ADO.NET(Managed Provider)를 사용하여, SQL 쿼리나 Stored Procedure를 실행하는 작업을 수행한다. Data Access Layer 에서 수행하는 역할은

일반적으로 다음과 같다. Business Rule에서 요청을 받은 후, 데이터베이스로 데이터를 보내거나 가져온다. 데이터베이스의 쿼리 결과를 Business Rule로 반환한다.

그 외에 추가적으로 다음과 같은 역할 및 기능을 부여할 수 있다. COM+ 서비스를 사용할 경우, COM+ 컴포넌트로 구현한다. Business Rule Layer에서

트랜잭션을 제어하게 되므로, Data Access Layer의 트랜잭션 옵션은 Supported로 지정해야

한다. 직접 ADO.NET 개체를 사용하는 대신에 이를 Wrapping 한 Data Access Helper Class를 작성하고 이를 통해 호출하는 것이 좋다.

일반적으로 Dac이라는 접미사를 붙인다. 일반적이거나 공통적인 동작을 처리해주는 기반 클래스(DacBase)에서 상속을 받도록

구현되는 것이 좋다. 이 경우, 궁극적인 상속 관계는 MyClass-▶DacBase-▶ServicedComponent가 된다.

이 계층을 디자인할 때는 다음과 같은 요소들을 고려해야 한다. Business Logic Layer에 종속적으로 작성되지 않도록 한다. 즉, Business Logic Layer의 메서드와 1:1로 매핑되지 않게 작성하는 것이다. Business Logic은 업무의 관점에서 컴포넌트 또는 클래스를 설계해야 하며, Data Access Layer는

데이터의 관점에서 컴포넌트나 클래스를 설계해야 한다. 통상적으로 1개의 테이블에 대응하도록 클래스를 작성한다. 필요에 따라서는 Business Logic Layer를 거치지 않고, Presentation Layer에서 직접

액세스하도록 작성할 수도 있다. 여러 개의 Data Source에 접근 시 방법, 트랜잭션 처리

원격 Data Source 사용 시에 접근 방법

25


2.2.2.3.1. Data Access Helper

Data Access Helper는 ADO.NET을 사용할 때 불필요하게 반복되는 코드를 줄여주고, 내부적으로 처리해주는 헬퍼 개체(Helper Object)이다. 또한 각종 DB에 관련한 설정을 읽고, 사용하는 코드가 포함되어 DB의 설정이 변경되었을 때 코드의 변경사항을 최소화하는 완충

계층의 역할을 한다.이러한 Data Access Helper는 직접 구현하거나 사전에 구현된 것(예 : Microsoft Application Blocks for Data의 SqlHelper)을 사용할 수 있다. 본 표준에서 예로 들고 있는 Framework에서는 SqlDbAgent라는 Data Access Helper를 사용하고 있다.

2.2.2.3.2. ADO.NET Data Provider

이전 ODBC의 드라이버나 OLE DB의 Provider와 유사한 개념으로, ADO.NET에서는 특정

데이터 소스에 접근하기 위해 ADO.NET(Managed Data Provider)를 사용한다. 이러한

Managed Data Provider는 각 벤더별로 제공이 된다..NET Framework 1.1에서는 기본적으로 다음과 같은 Data Provider를 제공한다.

SQL Server Data Provider ODBC Data Provider OLE DB Data Provider Oracle Data Provider (Microsoft)그 외 각 벤더들이 제공하는 3rd Party Data Provider가 있으며, 각 벤더 사이트에서 다운로드

받을 수 있다. Oracle Data Provider for .NET (Oracle) DB2 Data Provider for .NET (IBM) Data Direct Provider (Data Direct)전용 ADO.NET Data Provider를 제공하지 않는 Data Source의 경우에는 ODBC나 OLE DB Data Provider를 사용하여 접근하도록 한다.

2.2.2.4. Data Source Layer

이 계층은 실제 데이터를 저장하고 있으며, 데이터를 연산 및 조작하며, 요청에 따라 데이터를

주고 받는 역할을 수행한다. 통상적으로 이 계층은 관계형 데이터베이스로 구현되지만, 그 외에도

OODB, Hierarchical DB, Directory Service 등 다른 형태가 될 수도 있다.이 계층을 디자인할 때는 다음과 같은 요소들을 고려해야 한다.

Data Source에 접근하기 위한 방법

각종 환경 설정(예 : DTC 관련)

26


2.2.2.5. 기타 Layer

수직적인 계층 대신에 부가적으로 아키텍처의 모든 계층에서 사용될 수 있는 계층을 둘 수 있다. 보통 이 계층에는 유틸리티 기능이나 프레임워크와 같은 공통 기능을 구현한다.

2.2.3. 물리적 아키텍처 디자인

물리적 아키텍처는 하드웨어, 네트워크, 성능, 애플리케이션의 특성, 보안 등 다양한 요소에 따라

결정된다. 논리적 아키텍처가 일반적인 계층 구조가 있는 것에 비해, 물리적 아키텍처는 정해진

것이 없으며, 상황에 따라서 적절하게 선택해야 한다.논리적 아키텍처를 물리적으로 어떻게 배치하는가에 따라 다음과 같이 2-Tier, 3-Tier, N-Tier로

분류해 볼 수 있다. 이어서 각 물리적 아키텍처에 대해서 자세히 알아보도록 하자.

Business LogicBusiness LogicTierTier

Data AccessData Access

TierTier

Data SourceData Source Data Source Data Source

Data Access LayerData Access Layer

Business Logic Layer(Stored Procedure)

Data Access Layer Data Access Layer

Presentation Layer

Business Logic Layer


Presentation Layer Presentation Layer Presentation Layer

Intelligent

Client

Intelligent

Server

33--TierTier(Web Service/

Distributed App)


Business Façade

PresentationPresentationTierTier

22--TierTier

ProcessBoundary

ProcessBoundary

ProcessBoundary

ProcessBoundary

NN--TierTier

[그림 3] 물리적 아키텍처의 종류

2.2.3.1. 2-Tier

2-Tier Application은 클라이언트 애플리케이션이 서버에 있는 Data Source를 액세스 하는

방식이다. 2-Tier 는 Business Logic 을 어디에 두냐에 따라서 다음과 같이 2가지로 나눌 수 있다. Intelligent Server(또는 Fat Server, thin Client): 인텔리전트 서버 Application Architecture는 업무 규칙, 즉, 비즈니스 로직을 모두 서버에 두는 모델로서 인텔리전트

클라이언트와 반대되는 모델이다.

27


Intelligent Client(또는 Fat Client, rich Client) : 인텔리전트 클라이언트 Application Architecture는 업무 규칙, 즉, 비즈니스 로직을 모두 클라이언트에 두는 모델로서 인텔리전트

서버와 반대되는 모델이다.이 방식은 개념적으로 아주 쉽게 다가오는 모델이지만 여러 가지 단점을 가지고 있다. 다음은 2-Tier Application의 2가지 모델의 장단점을 비교한 것이다.

구분 Intelligent Server Intelligent Client속도 Stored Procedure를 사용할 경우

훨씬 더 빠를 수 있다.네트워크 측면에서 보면 빠르다.

네트워크 트래픽 많다. 적다

데이터 무결성 강력하게 유지된다. 개발된 클라이언트가 아닌 다른

클라이언트를 사용하면 업무규칙은

전혀 지켜지지 않는다.유지 보수 쉽다.

(서버에서만 업그레이드 하면

된다.)

어렵다.(모든 클라이언트의 업그레이드가

필요하다.사용자 인터페이스 서버에서 전달되는 메시지이므로

친근하지 못하다. 개발자가 다시

바꿔 줄 필요가 있다.

친근하다. 즉각적이다.

2.2.3.2. 3-Tier

3-Tier 애플리케이션 아키텍처는 2-Tier를 확장한 것으로, 재사용성과 유지보수를 위해

논리적으로 명확하게 구분된 Business Logic Layer를 별도의 서버(애플리케이션 서버)에 둔

것이다.이렇게 둘 경우, 비즈니스 로직이 Presentation Layer에 혼재되어 있는 2-Tier에서는 비즈니스

로직 변경 시 전체 클라이언트 애플리케이션을 업데이트해야 되는데 비해, 분리된 Business Logic Layer만을 변경하면 된다. 또한 Presentation Layer가 변경되더라도, 기존의 비즈니스

로직을 계속해서 재사용할 수 있다는 장점이 있다.3-Tier 아키텍처를 사용할 경우, 시스템 자원(System Resource)을 보다 효율적으로 관리할 수

있다. 예를 들어, 2-Tier 아키텍처에서는 동시 클라이언트 수만큼의 데이터베이스 연결을

요구한다. 그러나 비즈니스 로직 계층의 COM+는 동시 사용자 수보다 훨씬 적은 양의

데이터베이스 접속만을 요구하며 데이터베이스의 부하를 감소시켜 준다. 이는 시스템 자원뿐만

아니라 클라이언트에 데이터베이스 또는 레거시 시스템과 인터페이스 하기 위한 모듈(예: Oracle 클라이언트)을 배포, 환경 설정해야 하는 부담을 없애 준다.또한 3-Tier C/S 애플리케이션은 Scale-Out을 통해 확장해 나갈 수 있다. 사용자 수가 증가함에

따라 애플리케이션 서버의 수를 증가시키면 된다. 미들웨어를 사용할 경우 애플리케이션 서버

28


간의 로드밸런싱이나 Fail-Over 기능을 제공받을 수 있다.일반적으로 Business Logic Layer는 애플리케이션 서버에 탑재한 미들웨어(Middleware) 기반

하에서 구동하는 경우가 많다. Microsoft 플랫폼에서 제공되는 미들웨어는 Windows 2000 이상부터 OS에 포함되어 있는 COM+가 있다. COM+에서는 분산 트랜잭션, 동시성 관리, 개체

풀링, 애플리케이션 풀링, 적시 활성화(Just-In-Time-Activation) 등과 같은 다양한 서비스를

제공하여 프로그래밍 모델을 단순화시켜준다.

Database서버

Data Source

C/S Client(Managed Client)

C/S Client(Managed Client)

Win Form(C#, C++.NET,

VB.NET)

C, C++, Delphi

Stored Procedure

BusinessLogic Component

(C#,C++.NET, VB.NET)

COM+ ComponentCOM+ Component

Application 서버

.Net Remoting

DCOM

C/S Client(UnManaged Client)

[그림 4] 3-Tier Application Architecture 의 예

2.2.3.3. N-Tier (Distributed 3-Tier)

3-Tier를 보다 발전시킨 형태로, 웹 애플리케이션과 가장 잘 어울리는 아키텍처로서

애플리케이션을 보다 많은 계층으로 분리하여 설계/구현한 것이다. 논리적으로 여러 계층이

분리되어 있으므로 필요에 따라 각 계층별 확장이 가능하며 점진적으로 서버가 추가되더라도

애플리케이션의 수정을 최소화 할 수 있다. 이러한 장점으로 웹 사이트와 같이 확장성이 많이

요구되거나 복잡한 구조의 시스템을 구축 할 경우 적용할 수 있는 아키텍처라 할 수 있다.

29


Database서버

Data Source

Stored Procedure

인터넷인터넷인터넷인터넷인터넷인터넷Web ServiceClient App

Web ServiceClient App

BrowserBrowser

인트라넷인트라넷

BrowserBrowser



웹 서버

Listener

HTTP서버(ASP.NET)




In-process

Call

웹 서버

Listener

HTTP서버(ASP.NET)




Application 서버

웹웹 서버서버 단독단독

웹웹 서버와서버와 웹웹 어플리케이션어플리케이션 분리분리

[그림 5] N-Tier 아키텍처

2.2.3.4. SOA(Service-Oriented Architecture)

SOA는 분산 애플리케이션 아키텍처가 보다 진화된 형태로, 웹 서비스를 기반으로 하는

애플리케이션 아키텍처를 의미한다. 이 경우, 애플리케이션은 자기 내부가 아닌 외부의 서비스

공급자로부터 웹 서비스를 호출하여 동작을 수행하게 된다. 기존과는 다른 XML Messaging 기반의 비동기 모델이 사용되기 때문에 기존과는 다른 방식의 아키텍쳐 설계가 필요하다

30


Supplier B Supplier B

DB ServerDB Server

Supplier A Supplier A

Supplier C Supplier C

Smart DeviceSmart Device((다양한다양한 클라이언트클라이언트 환경환경))

YourYourWeb ApplicationWeb Application

YourYourWeb ApplicationWeb Application

클라이언트클라이언트 PCPC

Web ServicesWeb Services

HTTP

SOAP

SOAP

SOAP

SOAPSOAP

[그림 6] 웹 서비스를 이용한 웹 애플리케이션

2.2.4. N-Tier에서 서버 배치 모델

통상적으로 N-Tier 환경에서는 단일 서버가 아닌 여러 대의 서버가 가용한 경우가 많다. 이 때

여러 대의 서버를 어떤 역할로 활용할 것인지도 사전에 결정해 두는 것이 좋다. 배치 모델은 크게

Web Farm 모델과 Dedicated 모델의 2가지가 존재한다.Web Farm 모델 Dedicated 모델

설명 모든 서버에게 동일하게 애플리케이션이

배치되며, 로드밸런싱됨

웹 서버, 애플리케이션 서버로 각각의

역할에 따라 전담 서버로 분리

장점 배치, 확장이 간편

상대적으로 높은 성능

애플리케이션 구성이 간편(원격 호출

시나리오를 신경 쓸 필요 없음)Fail-over 및 로드밸런싱 제공

1:1인 경우는 로드밸런싱 구성이

필요없음

병목(Bottleneck) 진단이 명확

애플리케이션 서버 접근 시 별도 보안

설정 가능

단점 로드밸런싱 구성(S/W or H/W)이 필요

병목(Bottleneck) 진단이 어려움

웹 애플리케이션 상태 정보 공유에 대해

고려해야 함

배치, 확장이 다소 불편

마샬링, 네트워크 트래픽으로 인한 성능

저하

애플리케이션 구성이 불편(원격 호출

시나리오, 환경 설정이 필요)Fail-over를 제공하지 못함

31


1:n, n:n으로 가는 경우, Fail-over를

제공할 수 있으나, Web Farm 모델의

단점이 역시 나타남

일반적으로 Microsoft에서는 Web Farm을 통한 Scale-out을 권장하고 있다. Dedicated 모델은

1:1 시나리오에서는 Web Farm 모델에 비해서 장점을 제공하기도 하지만, Fail-Over나 로드

밸런싱을 위해 1:n 또는 n:n 시나리오로 구성하는 순간 Web Farm 모델이 가지는 모든 단점이

역시 나타나게 된다. 그러므로, 특별한 경우가 아니라면 가급적 Dedicated 모델 대신에 Web Farm 모델을 선택하도록 한다.각 모델 상에서 Logical Tier을 배포하기 위한 시나리오들을 살펴보도록 하겠다.

2.2.4.1. Web Farm 모델

앞서 언급했듯이 Web Farm 모델은 구성되는 서버군 내의 각각의 서버에 모두 동일하게

애플리케이션이 배치되며, 로드 밸런싱 구성(NLBS, L4 Switch 등)을 통해 묶이게 된다. 그러므로 도식되는 그림이 서버 개수만큼 n개 존재할 수 있다고 생각하기 바란다.

2.2.4.1.1. InProcess 모델

모든 구성요소를 ASP.NET 프로세스 내에서 InProcess 모드로 동작시키는 형태로, 일반적인

Web Farm 모델에서 가장 권장되는 모델이다. 이 경우, COM+ 컴포넌트들은 모두 라이브러리

활성화(Library Activation)로 동작하게 된다.

32


[그림 7] Web Farm – InProcess 모델

장점

애플리케이션 배치, 구성이 쉽다. 새로 서버가 추가되었을 때 전체를 복사만 해주면 되므로, Scalability가 높다. web.config 파일에 모든 요소들의 설정을 통합해서 관리할 수 있다. InProcess 모드이므로 성능이 가장 빠르다. 원격 호출 인프라에 대해서 신경 쓰지 않아도 된다. 개발, 디버깅이 쉬우며, Self-Registration및 Shadow-Copy를 100% 활용할 수 있다. 차후 .NET 리모팅이나 XML 웹 서비스로 쉽게 확장 가능하다.단점

Tier 별로 별도로 보안 권한 설정을 할 수 없다

(web.config를 통한 Impersonation은 가능) 웹 애플리케이션 단의 보안, 인증이 전체 보안 권한을 좌우한다. Bottleneck 발생 시에 진단, 검출이 어렵다.2.2.4.1.2. Out-Of-Process 모델 1

전체 Tier 중에서 COM+ 컴포넌트에 해당하는 요소들을 서버 활성화로 구동하는 동작시키는

형태이다. 서버 활성화로 동작하는 컴포넌트들은 Dllhost.exe라는 별도의 전용 프로세스에서

구동된다. 이전 VB 6.0 등을 사용해서 Unmanaged COM+ 개발 시에 서버 활성화로 사용을

많이 했었지만, .NET에서는 별로 권장되지 않는다. 반드시 별도 보안 권한이 필요한 경우에만

사용하기 바란다.

33


[그림 8] Web Farm – Out-Of-Process 모델 1

장점

서버 증설 시 애플리케이션 배치, 구성이 비교적 쉽다. 원격 호출 인프라에 대해서 신경 쓰지 않아도 된다. 서버 활성화 컴포넌트에 별도의 보안 권한 설정을 할 수 있다. aspnet_wp.exe와 dllhost.exe 두개로 나누어서 Bottleneck을 살펴 볼 수 있다.단점

web.config 하나에서 전체 설정을 통합 관리하는 것이 사실상 불가능하다. InProcess 모드에 비해서 성능이 저하된다. (약 30%) 컴포넌트를 업데이트 시 COM+ 애플리케이션을 종료시켜야 한다. 마샬링 시 발생가능한 문제에 대해 고려해야 한다. 그대로 리모팅이나 웹서비스로 확장한 경우, 성능이 크게 저하된다. 원격호출을 통한

마샬링과 Dllhost.exe로의 마샬링, 즉 마샬링이 2번 일어나기 때문이다.2.2.4.1.3. Out-Of-Process 모델 2

Presentation Layer가 Business Logic 컴포넌트를 호출할 때, 리모팅이나 XML 웹 서비스를

통해 호출하는 경우이다. 이 모델은 이론적으로는 가능하나, Web Farm 모델에서는 불필요하다. 동일 머신에 있는 컴포넌트를 굳이 원격 호출을 통해 부를 필요가 없기 때문이다. 만약 타

시스템에서 Business Logic 컴포넌트에 접근할 경우에는 사용이 가능하나, 이 경우에도 타

시스템이 아닌 Presentation Layer는 InProcess 모델로 접근하게 하는 것이 좋다.

34


리모팅의 호스트는 ASP.NET이 아닌 .EXE, 윈도우 서비스등 다른 사용자 정의 호스트가 될 수도

있으나, 보통 IIS를 통해 사용한다. 리모팅이나 XML 웹 서비스를 통해 실행될 경우, Presentation과 Business Logic은 동일한 프로세스이나 별도의 AppDomain에서 실행된다는

것에 유의한다.

[그림 9] Web Farm - Out-Of-Process 모델 2

장점

새로 서버가 추가되었을 때 전체를 복사만 해주면 되므로, Scalability가 높다. 다른 시스템에서도 Business Logic을 호출할 수 있다. Presentation과 호스트를 위한 web.config를 통해 전체적인 구성 정보를 관리할 수

있다. 개발, 디버깅이 쉬우며, Self-Registration및 Shadow-Copy를 100% 활용할 수 있다.단점

성능이 저하된다. 리모팅이나 웹 서비스 구성 및 설정을 위한 추가 작업이 필요하다.

2.2.4.2. Dedicated 모델

Dedicated 모델은 크게 웹 서버와 애플리케이션 서버로 각 서버들의 역할을 분리시켜서

애플리케이션을 배치하는 경우를 말한다. Presentation Layer는 웹 서버로, 나머지 요소들은

애플리케이션 서버로 분산해서 배치하게 된다(일반적으로 Business Rule, Data Access를 다시

나누어서 배치하는 경우는 드물다).

35


이 경우, Presentation Layer는 별도의 머신에 존재하는Business Logic 애플리케이션과

통신하기 위해서 원격 호출을 필요로 한다. 원격 컴포넌트의 메서드를 호출하는 방법을 .NET에서는 3가지로 제공하고 있으며, 이 3가지 방법들에 대해 각각 살펴 보도록 하겠다.

2.2.4.2.1. DCOM RPC를 사용

원격 COM+ 컴포넌트를 호출하는 기본적인 방법으로, 서버 활성화로 작성된 COM+ 컴포넌트에

대해 Proxy를 만들어 낼 수 있다(내보내기 명령 사용). 만들어진 COM+ Proxy를 Presentation Layer가 있는 웹 서버 쪽에 설치하고, Presentation Layer에서는 이 Proxy를 참조해서

호출한다. Proxy는 자동적으로 메서드 호출을 DCOM RPC(Remote Procedure Call) 프로토콜로 변환하여, 원격에 있는 COM+ 컴포넌트를 호출하게 된다.

장점

COM+의 모든 장점을 100% 활용할 수 있다(패킷보안, Role-based 보안 등) 만약 다른 시스템의 COM+에서 Business Logic을 호출한 경우, 트랜잭션 컨텍스트가

전달된다. 원격 호출 방법 중 속도가 가장 빠르다.단점

COM+ Proxy를 설치해야 한다. Business Logic이 변경되거나 애플리케이션 서버 위치가 변경되면, Proxy를 새로

생성해서 재설치가 필요하다(코드 상으로도 가능하긴 하지만, 매우 어려움) RPC 프로토콜은 135번 포트를 사용하므로, Firewall 설정이 필요하다. 애플리케이션 서버를 로드밸런싱하는 경우에는 ApplicationCenter라는 별도의 제품을

구매해야 한다. Web Farm - Out-Of-Process 모델 1 에 나온 단점을 모두 가진다.

36


2.2.4.2.2. .NET 리모팅을 사용

Presentation에서 Business Logic을 호출할 때, .NET 리모팅을 사용해서 원격 호출을

수행한다. 웹 서버에는 리모팅 호출을 위한 어셈블리와 리모팅 호출에 필요한 설정을 한다. 애플리케이션 서버에는 Business Logic을 배치하고, Business Logic을 노출하기 위해 리모팅

래퍼(Business Façade)로 감싼 다음, 리모팅 호스트 어플리케이션을 작성하거나, IIS를

사용하여 리모팅 호스트 설정을 해주면 된다. 리모팅 호스트는 통상 IIS를 사용한다. Dedicated 모델을 반드시 사용해야 하거나, Presentation Layer가 WinForm인 경우에는 이 모델을

사용하는 것이 바람직하다.

장점

구성 파일 설정을 통해 유연하게 리모팅 호출 설정을 구성할 수 있다. 사용하는 프로토콜, 포맷을 자유롭게 선택할 수 있다. HTTP를 사용 가능하므로, Firewall 간에도 이상없이 사용 가능하다. XML 웹 서비스에 비해 상대적으로 속도가 빠르다 (Binary 포맷인 경우). J2EE 시스템에서도 브리지 S/W를 사용하면 호출이 가능하다

(J2EE와의 상호 운용에 관한 내용은 별도 문서를 참조한다). 자유롭게 확장 가능한 아키텍처다. .NET to .NET에 최적화되어 있다. IIS에서 호스팅되므로, 웹 서버처럼 로드밸런싱을 통한 확장이 가능하다.단점

리모팅 호출 설정에 대한 관리가 필요하다.

37


RPC에 비해 성능이 상대적으로 떨어진다. SOAPSUDS의 제한으로, 호출하려는 Type이 들어 있는 어셈블리를 클라이언트가

가지고 있어야 하는 경우가 많다. 브리지 S/W가 없으면 이기종 시스템에서는 호출이 불가능하다.2.2.4.2.3. XML 웹 서비스를 사용

Presentation에서 Business Logic을 호출할 때 XML 웹 서비스를 사용해서 호출한다. Presentation에서는 해당 웹 서비스의 WSDL을 내려받아, 웹 서비스 호출에 필요한 Proxy를

만들 수 있다. Business Logic은 웹 서비스 파일(*.asmx) 및 웹 서비스 클래스에 의해서

래핑되어서 제공된다. Presentation에서 웹 서비스 Proxy를 통해 호출하면 SOAP 호출로

변환되어 웹 서비스에 전달된다. 이기종 시스템에서 호출이 필요한 경우에는 XML 웹 서비스를

사용하는 것이 편리하다.

장점

WSDL 파일을 내려받아 Proxy 구성이 가능하다. HTTP 프로토콜을 기반으로 하므로, Firewall 간에도 이상없이 사용할 수 있다. 이기종 시스템 간에 높은 호환성을 가진다. 업계의 표준으로 자리잡아 가고 있다. WS-I를 통한 웹 서비스의 확장 셋을 차후에 도입할 수 있다. ASP.NET에서 native하게 지원한다.단점

상대적으로 성능이 낮으므로, 호출 Frequency가 많은 시스템에는 적합하지 않다. 웹 서비스가 갱신된 경우, Proxy를 업데이트해야 한다.

38


2.2.5. .NET 관련 기술 정리

다음은 애플리케이션 아키텍처에서 사용되는 .NET의 관련 기술들을 정리한 표이다.Technology .NET 제품 비고

Support Technologies프로그래밍 툴 Visual Studio .NET분산 프로토콜

DCOM, SOAPUnmanaged code로 작성된 경우 DCOM 을 사용

Firewall ISA*Presentation tier Technologies하부구조(Infrastructure) IIS Windows 에 포함

프로그래밍 모델 ASP.NET(Web) Windows Form(C/S)

고 가용성 보장

NLBS*, ACS*,Windows 에서 제공하는 Network Load Balancing이용

Load balancing NLBS*,ACS*Management ACS*(Application Center

Server), MOM*Business Logic tier Technologies하부구조(Infrastructure) COM+ Windows 에서 제공

고 가용성 보장 ACS*Load balancing ACS*보안 API COM+ Security Call Context메시지 큐 API MSMQ비동기식(Asynchronous) 컴포넌트 Queued(COM+)네이밍(Naming) 및 디렉토리(Directory) 서비스 ADSI

Data tier Technologies분산 트랜잭션 MS-DTC관계형(Relational ) DB API ADO.NET구조적(Hierarchical) DB API ADO.NET데이터베이스 저장소(Storage) SQL Server 2000Mainframe DB 연결 HIS*(Host Integration Server)Framework Technologies전자상거래(eCommerce) 프레임워크 Commerce Server*B2B 통합 BizTalk Server*

39


2.3. 시스템 아키텍처 디자인

시스템 아키텍처는 시스템을 구성하는 네트워크, 하드웨어, 시스템 소프트웨어 등의 구조를

말한다. 시스템 아키텍처는 네트워크 환경, 사용하는 하드웨어 및 소프트웨어에 따라 매우

다양하다. 이 장에서는 다양한 시스템 아키텍처들 중에서 대표적인 몇 개를 살펴보기로 한다.시스템 아키텍처를 크게 네트워크 아키텍처와 하드웨어 아키텍처로 나누어 설명할 것이다. 또한

시스템 아키텍처에 영향을 미칠 수 있는 클러스터링 기법 중 Windows에서 제공하고 있는 것은

어떤 것인지를 알아본다.네트워크 아키텍처에서는 시스템 구축 시 전형적으로 나타나는 인터넷 및 인트라넷 구성을

살펴 볼 것이다. 또한 네트워크에 관련된 여러 장비 및 구성들에 대해서도 다룬다.하드웨어 아키텍처에서는 데이터베이스 서버, 애플리케이션 서버, 웹 서버의 전형적인

하드웨어 사양에 대해 살펴본다. 각 서버를 선택할 때 고려할 사항들이 제시되며 일반적으로 많이

사용되는 각 서버의 CPU 개수, 메모리, 디스크 등의 스펙을 제시한다.클러스터링은 시스템의 성능, 확장성, 가용성을 높이기 위해 여러 서버를 하나의 서버처럼

묶는 것을 말한다. Windows에서 제공하는 데이터베이스 레벨의 클러스터링, 애플리케이션 서버

레벨의 클러스터링, 웹 서버 레벨의 클러스터링 구성과 이들이 주는 장점 등을 살펴볼 것이다.

2.3.1. 네트워크 아키텍처

여기서는 네트워크 아키텍처를 인트라넷과 인터넷으로 나누어 살펴볼 것이다. 네트워크

아키텍처는 MS 기술 및 제품과 크게 연관이 없는 일반적인 것이므로 전형적인 인트라넷 네트워크

구조와 인터넷 네트워크 구조를 간략히 살펴볼 것이다.

2.3.1.1. Intranet 아키텍처

인트라넷이라 함은 기업 내부의 LAN/WAN 환경을 말하며 방화벽(firewall)을 이용하여 외부

인터넷으로부터 차단되어 있다. 대부분의 경우 이더넷(Ethernet)과 TCP/IP를 기본으로 한다. 경우에 따라 백본(backbone)으로 ATM이나 FDDI와 같은 네트워크를 사용하기도 하는데 PC와

서버는 이더넷을 사용하는 것이 보다 일반적이다. 이더넷의 경우 10Mbps의 대역폭을 사용하는

것이 기본이지만 서버는 100 Mbps를 PC는 10Mbps를 사용한다. 따라서 서로 다른 대역폭을

사용하는 서버와 PC를 연결하기 위해 허브와 같은 네트워크 장비가 필요하다.허브는 여러 네트워크 선을 묶어 연결해주는 역할을 한다. 더미 허브는 단순히 이더넷을 연결만

해준다. 예를 들어 하나의 허브에 10명이 연결되어 있다면 10명이 10 Mbps 대역폭을 나누어

사용하는 것이다. 반면 스위칭 허브(Switching Hub)는 네트워크 연결 뿐만 아니라 효율적인

연결 스위칭을 통해 네트워크 사용율을 높여준다. 더미 허브 대신 스위칭 허브를 사용하는 것이

좋겠지만 스위칭 허브는 고가의 장비이므로 서버들이 스위칭 허브와 직접 연결되어 있고 스위칭

허브를 다시 더미 허브와 연결하는 형태가 일반적이다.

40


클라이언트 PC와 서버가 몇 대가 존재하는가에 따라 여러 개의 스위칭 허브가 존재할 수도

있으며 필요에 따라 PC나 워크스테이션 급의 컴퓨터가 스위칭 허브에 직접 연결되는 경우도

있다. 물론 이러한 컴퓨터는 소수이며 서버와의 데이터 통신량이 많거나 서버와 고속 네트워크

통신을 해야 하는 경우에만 해당된다. 또한 IP가 B 클래스 한 개를 사용하는가 혹은 C 클래스 여러

개를 사용하는 가에 따라 라우터가 추가적으로 필요할 수도 있다. 이처럼 네트워크 구성은

시스템에 따라 다양하게 변화될 수 있음에 유의해야 한다. 상세한 네트워크 구성에 대한 내용은

본 문서의 범위에서 벗어나므로 네트워크와 관련된 컨설팅을 받는 것이 좋다.

SwitchingHub

HubHub

Database Server

Application Server

File ServerDNS(or WINS Server):optional

Clients Clients

100Mbps Fast Ethernet

10Mbps Ethernet

WorkStation

[그림 10] 일반적인 인트라넷 네트워크 구성

기업의 지역적인 분할로 인해 WAN이 사용되는 경우도 있는데, 이 경우 프레임 릴레이(Frame Relay) 네트워크를 이용하여 전용선으로 연결되기도 한다. WAN은 일반적으로 LAN 보다

대역폭이 낮으며 발생되는 트래픽에 따라 56Kbps, 128Kbps, 256Kbps, 512Kbps, T1(1.5Mbps), E1(2.1 Mbps) 등의 대역폭을 사용한다. WAN을 사용하기 위해서는 전용선 연결

장비인 DSU/CSU1를 필요로 하고 TCP/IP 라우팅을 위한 라우터(Router) 역시 필요하다. DSU/CSU는 별개의 제품으로 만들어지지만, 때로는 라우터(Router)와 통합되기도 한다. WAN 전용선으로 연결된 네트워크는 논리적으로 LAN과 큰 차이가 없다. 다만 낮은 대역폭으로

연결되어 있다는 점에서만 차이가 날 뿐이다. WAN으로 연결된 두 네트워크에서 주의할 점은

NetBIOS, IPX와 같은 몇몇 프로토콜은 WAN에서 사용할 수 없다는 점이다. 따라서 WAN으로

연결된 두 네트워크 사이의 통신은 TCP/IP를 이용해야 한다.

1 56/64Kbps 이하의 전용선은 DSU 를 128Kbps 에서는 CSU 를 사용

41


SwitchingHub

HubHub

Clients ClientsClients

WAN(Frame Relay)

WAN(Frame Relay)

CSU CSU

256K/ 512KT1/ E1

Server Group 1 Server Group 2

Router RouterSwitching

Hub

[그림 11] WAN 으로 연결된 인트라넷

인트라넷은 일반적으로 C/S 애플리케이션과 밀접한 연관이 있다. C/S 애플리케이션이 인트라넷

상에서 수행되는 MIS 정보 시스템을 타겟으로 하고 있기 때문이다. 인트라넷 네트워크

아키텍처의 핵심은 효율적인 네트워크 구성을 통한 서버 활용도를 증대 시키는 것이다. 잘못된

네트워크 구조는 서버 활용도를 떨어뜨려 전체적인 애플리케이션 성능을 저해하는 요소로

작용한다. 예를 들어 느린 대역폭의 WAN으로 연결된 데이터베이스 서버에 다량의 데이터를

조회하는 일은 없도록 해야 할 것이다. 서버의 CPU 활용도가 높지 않음에도 불구하고

애플리케이션의 응답 시간(response time)이 좋지 못한 경우, 네트워크 구성을 의심해 볼

필요가 있다. 특히, 서버 측의 네트워크 구성이 병목 지점이 될 가능성이 높으므로 이점을 유의

깊게 살펴보아야 할 것이다.

2.3.1.2. Internet 아키텍처

여기서 말하는 인터넷이라 함은 인터넷 웹 서비스를 위한 기업의 네트워크 환경을 말한다. 따라서

웹 애플리케이션의 네트워크 구성과 관련이 깊으며 이 네트워크 구성을 어떻게 하는가에 따라서

웹 애플리케이션의 응답 시간에 큰 차이를 드러낼 수도 있다.기업의 인터넷 접속 환경의 구성은 인터넷과 연결하는 전용선, 이 전용선과 연결을 위한 네트워크

장비(CSU, Router), 방화벽, 그리고 방화벽과 인트라넷의 연결을 꼽을 수 있다. 인터넷 전용선은

ISP 사업자를 통해 매월 일정 사용료를 내고 회선을 임대하여 사용한다. 회선 결정의 기준은

얼마나 많은 사용자에게 인터넷 서비스를 제공하는가에 달려 있다. 하루 방문자 수나 최대 동시

사용자 수를 기준으로 약 10~ 15% 정도 여유 있게 회선을 임대하는 것이 좋다. 그러나 하루

방문자 수 혹은 동시 사용자 수를 미리 예측하기 어려울뿐더러 웹 애플리케이션의 페이지 구성

등에 따라 동시 사용자 수가 같더라도 더 많은 대역폭을 필요로 하는 경우도 있기 때문에 회선

선정에 어려움을 겪게 된다. 동시 사용자 수가 500 미만이며 동영상 서비스가 포함되어 있지

42


않다면 대부분 T1 정도의 회선으로 충분하다. 필요에 따라 T1 혹은 E1을 추가적으로 배치하는

것이 가능하므로 초기에 너무 큰 회선을 임대하는 것은 낭비일 수 있음에 유의한다.일반적으로는 아래 그림과 같이 인트라넷을 인터넷에 통합함으로써 업무의 효율화를 꾀한다. 이는 지금까지 따로 사용했던 사무용 프로그램과 인터넷프로그램을 통합한다는 개념. 즉

인터넷을 사용하면서 그 안에서 사내메일을 보내고 문서작성 표 계산 자료보관 등을 할 수 있다. 즉 프로그램을 옮겨 다닐 필요 없이 인터넷 프로그램 하나로 모든 업무와 정보획득 이 가능하다.

Internet Web Clients

CSU CSU

T1/ E1

DB Server

Firewall

Router

SwitchingHub

Internet

T1/ E1

Web ServersGroup

Application ServerGroup

Internet

Intranet

[그림 12] 인터넷과 인트라넷의 연결

인터넷 접속 환경의 설계는 인터넷 서비스와 인트라넷 네트워크의 효율을 높이는 방법으로

구성되어야 한다. 부적절한 네트워크 설계는 인터넷 서비스와 인트라넷 서비스의 성능을 둘 다

낮추는 결과를 초래하기도 한다. 인터넷 액세스, 즉 HTTP 서비스는 웹 서버에만 도달하도록

라우터, 방화벽, 스위칭 허브를 설정해 주어야 한다. 또한 공인 IP를 사용하지 않고 비공인 IP를

사용함으로써 인트라넷의 보안 향상을 고려해 볼 수도 있다. 인터넷 액세스로 인해 인트라넷의

성능을 떨어뜨리지 않게 하는 방법으로 네트워크를 분리하는 방법을 꼽을 수 있다. 즉, 웹 서버에

2개의 NIC를 설치하여 내부 네트워크 용 NIC, 외부 네트워크 용 NIC를 분리시키면 인터넷

트래픽에 의해 인트라넷 트래픽이 방해 받지 않도록 할 수 있다. 많은 인터넷 사용자를 지원해야

하며 여러 대의 웹 서버를 사용하는 경우는 이러한 구조를 고려해 보아야 한다. 여러 대의 웹

서버를 사용하는 경우에는 라우터를 하나 더 배치하여 Private network과 분리되는 하나의

서브넷(subnet)으로 그룹핑 될 수 있다.

43


Web Server Group

InternetRouter

10/ 100 Mbps

Internet

SwitchingHub

DB Server

Hub Hub

Application Server Group

Subnet Router

10 Mbps 10 Mbps

100 Mbps

Intranet

L4 Switch

[그림 13] 인터넷과 인트라넷의 분리

이처럼 인터넷 환경 역시 그 목적과 방법에 따라 매우 다양한 형태가 나타날 수 있으므로 사내

네트워크 전문가로부터 조언 혹은 컨설팅을 받는 것이 좋다.

2.3.2. 하드웨어 아키텍처

이번에는 전형적인 하드웨어 구성을 살펴볼 것이다. 즉, 서버 하드웨어는 전형적으로 어떠한

스펙을 갖추어야 하며 서버 선택 시 고려사항은 어떠한 것들이 있는지 데이터베이스 서버, 애플리케이션 서버, 웹 서버에 대해 각각 살펴보도록 하겠다.

2.3.2.1. 데이터베이스 서버

데이터베이스의 특성은 웹 서버나 애플리케이션 서버와 달라서 로드 밸런싱을 구현하기 매우

어렵다. 웹 서버의 경우 HTML이나 ASP 파일들을 각 웹 서버에 중복시킴으로써 로드 밸런싱을

구현할 수 있지만 데이터베이스의 경우 데이터를 복수개의 서버에 분산시키기 어렵다. 따라서

데이터베이스 서버로 대형 서버를 사용하는 것이 좋으며 대형이 아니더라도 Scale-Up을 통해

충분한 확장성을 갖는 서버를 채택하는 것이 이상적이다.다음은 데이터베이스 서버의 서버용량 산정 요소, 주요 자원, 특이사항 등을 정리한 것이다.

44


구분 결정요인 비고

서버 용량 데이터의 양, 트랜잭션 빈도, 동시

사용자 수

인터넷 애플리케이션의 경우, 일시적

폭증이 일어날 수 있으므로 충분하게

여유있게 산정하는 것이 좋음

애플리케이션 아키텍처에 따라서

지원가능한 사용자 수가 변경 가능

주요 자원 프로세싱 자원(CPU, 메모리) 예산 내에서 최대한 확보

디스크 I/O SCSI, RAID 등을 권장

특이사항 데이터 백업 필요 대용량 백업 디바이스 필요

확장성 로드밸런싱 구현이 어려움 Scale-Up을 권장

2.3.2.2. 애플리케이션 서버

애플리케이션 서버는 비즈니스 로직 컴포넌트를 구동하는 서버로, 2-Tier 애플리케이션

아키텍처에서는 나타나지 않으며 3-Tier 이상에서만 나타난다. 이 서버 상에서는 주로 COM+ 컴포넌트 서비스, MSMQ, HIS(Host Integration Server) 등이 수행된다.애플리케이션 서버는 디스크 I/O보다는 프로세싱이 많이 일어나므로 CPU와 메모리가 주요

고려사항이 된다. 애플리케이션 서버는 복제(replication)와 로드 밸런싱을 통해 확장하기가 쉽기

때문에, 고성능의 서버 1대보다는 여러 대의 서버가 존재하는 것이 더 효율적이다. 예를 들어 4개의 CPU를 가진 애플리케이션 1대보다는 2개의 CPU를 가진 서버 2대가 훨씬 더 좋은 성능을

낸다.애플리케이션 서버의 용량 산정에서 동시 사용자 수는 가장 중요한 요소이다. 그러나 동시 사용자

수를 예측하기란 매우 어려우며 특히 인터넷 웹 애플리케이션의 경우는 더더욱 그러하다. 대개

1000개의 C/S 클라이언트를 갖는 애플리케이션의 동시 사용자 수는 80~100명 안팎이다. 즉, 어느 한 시점에서 COM+ 컴포넌트를 사용중인 클라이언트의 수가 80~100 이라는 것이다. 동시

사용자의 수가 100이라는 말은 애플리케이션 서버에서 동일한 컴포넌트가 동시에 100개 이상

수행 중일 수 있다는 것을 의미하며 애플리케이션 서버는 200 ~ 300개 이상의 컴포넌트를

동시에 수행시킬 수 있는 능력을 갖추어야 한다. 한편 웹 애플리케이션의 경우 불특정 다수가

동시 애플리케이션 서버를 액세스 하고자 할 수 있으므로 동시 사용자의 수를 예측하기란 더욱 더

어렵게 된다. 데이터베이스의 경우와 마찬가지로 애플리케이션 서버의 용량 역시 애플리케이션에

따라 기준이 달라질 수 있음을 잊지 말아야 한다. 동일한 사양의 서버라도 애플리케이션에 따라

더 많은 동시 사용자를 수용할 수도 있으며 더 적은 동시 사용자만을 지원할 수도 있다. 애플리케이션 서버는 데이터베이스 서버와는 달리 필요한 CPU와 메모리의 양을 정량적으로

계산하기 매우 어렵다. 하나의 COM+ 컴포넌트가 차지 하는 메모리나 CPU 점유율을 미리 예측할

수 없기 때문이다. 그래서 대부분 경험에 의해 애플리케이션의 용량을 결정하게 된다. 시스템

오픈 전에 애플리케이션 서버에 충분한 부하를 주어 테스트하는 스트레스 테스트(stress test)를

수행하여 얼마 정도의 부하를 견디어 내는지 미리 알아보고 대처를 해야 한다. 이 테스트는

45


애플리케이션의 핵심 부분에 대해서만 수행해도 되므로 프로젝트 개발의 중간 단계에서부터

반복적으로 수행해 볼 필요가 있다.COM+ 컴포넌트 서비스를 사용하는 경우 여러 대의 애플리케이션 서버를 로드밸런싱 및

클러스터링 하려면, Application Center Server라는 제품을 사용해야 한다는 것에 유의하기

바란다. COM+ 클러스터링은 Windows에서 기본적으로 지원되지 않는다..NET 리모팅이나 웹 서비스를 사용하는 경우에는 웹 서버의 경우와 동일하게 NLB(Network Load Balancing)이나 L4 Switch를 사용하여 로드밸런싱을 할 수 있다.

구분 결정요인 비고

서버 용량 동시 사용자 수 사전 스트레스 테스트를 통해 부하

측정 후 산정

주요 자원프로세싱 자원(CPU, 메모리) 복수 애플리케이션 서버 사용 시 2

CPU를 권장

특이사항 COM+ 클러스터링, 로드밸런싱 Applicatin Center Server 필요

.NET 리모팅, 웹 서비스 NLB, L4 Switch로 로드밸런싱

확장성 로드밸런싱 구현이 쉬움 Scale-Out을 권장

2.3.2.3. 웹 서버

웹 서버는 사용자로부터 HTTP 요청을 받아 애플리케이션 서버에 전달한 후, 결과를 HTML로

렌더링하여 HTTP로 응답해 주는 역할을 수행한다. 웹 서버의 경우 프로세싱과 I/O가 둘 다 중요한 요소로 작용한다(대신 데이터베이스만큼 I/O가

중요하지 않으며 애플리케이션 서버만큼 프로세싱이 중요하지 않다). I/O의 중요성은 웹 서비스가

HTML/ASP.NET 파일과 이미지 파일(GIF, JPEG)을 매우 자주 액세스하기 때문이다. 프로세싱은

ASP.NET이 CPU를 점유하기 때문에 중요한 요소가 된다. 따라서 빠른 디스크 액세스와 적절한

수의 CPU 및 메모리를 필요로 한다. 물론 디스크 어레이를 사용하여야 하며 디스크의 크기도

컨텐츠에 맞추어 적절한 크기를 확보해야 한다. 대부분 동적으로 페이지가 생성되므로 정적인

페이지를 위한 디스크를 확보하면 된다. 10~20 GB의 디스크로 대부분의 웹 애플리케이션을

커버할 수 있다. 그러나 동영상 미디어 서비스를 하고자 한다면 필요로 하는 디스크의 크기는

훨씬 더 늘어난다.웹 서버는 직접 사용자와 인터페이스를 수행하므로 가능한 한 최소의 응답시간을 제공해야 한다. 때문에 소규모가 아니라면 웹 서버는 2개 이상을 사용하여 로드 밸런싱을 해주어야 한다. 특히

인터넷 웹 서비스의 경우라면 2개 이상의 웹 서버 사용을 반드시 고려해 보아야 한다.웹 서버는 애플리케이션 서버와 동일하게 확장성이 그다지 중요한 사항이 아니다. 웹 서버에

추가적인 CPU와 메모리를 장착하는 것보다 추가적인 웹 서버를 배치하는 것이 성능과 효율을

모두 증대 시킬 수 있을 뿐더러 하나의 웹 서버가 다운되더라도 웹 서비스는 지속될 수 있기

때문이다. 이 때문에 확장성이 낮지만 가격이 상대적으로 비싸지 않은 웹 서버를 여러 대

46


사용함으로써 비용대비 효과를 극대화하는 방향으로 시스템을 설계하는 것이 좋다.웹 서버의 용량 산정 역시 동시 사용자 수가 중요한 요소이다. 애플리케이션 서버의 용량 산정과

비슷하게 웹 서버 역시 명확하게 용량을 산정하기 어렵다. 인트라넷의 경우는 다행이 최대 사용자

수, 동시 사용자 수를 추측할 수 있지만 인터넷의 경우는 추측이 매우 어렵다. 특히 인터넷 웹

사용자는 단순한 방문만으로 끝나는 경우가 많다. 예를 들어 웹 사이트의 첫 페이지만을 보고

다른 사이트로 이동하는 사용자는 애플리케이션 서버의 컴포넌트 호출 없이 단순한

HTML/ASP.NET 파일 서비스만 받는 경우 이다. 이렇기 때문에 하루 수만 명의 사용자가 있다

하더라도 애플리케이션 서버에 부하를 주는 사용자는 그다지 많지 않다. 또 한가지 웹 사용자의

특성은 대부분의 사용자가 애플리케이션을 오랫동안 사용하지 않는다는 점이다. 이 때문에 하루

사용자 수가 수만 명에 달할 수 있는 것이다. 웹 서버 역시 스트레스 테스트를 통해 얼마 정도의

부하를 견디어 내는지 미리 알아보고 대처 해야 한다. 웹 서버의 특성상 추가적인 웹 서버의

배치가 상대적으로 용이하므로 웹 서버의 용량이 부족하다고 판단되면 즉각적인 서버 투입이

이루어져야 한다.구분 결정요인 비고

서버 용량 동시 사용자 수 사전 스트레스 테스트를 통해 부하

측정 후 산정

주요 자원프로세싱 자원(CPU, 메모리) 2 CPU 권장(그 이상은 비용대비

효과낮음)디스크 I/O RAID 사용 권장

특이사항 로드밸런싱 NLB, L4 Switch로 로드밸런싱

확장성 로드밸런싱 구현이 쉬움 Scale-Out을 권장

2.3.2.4. 개발 서버

개발 서버는 애플리케이션 개발을 위한 서버로서 데이터베이스 서버, 애플리케이션 서버, 웹

서버의 역할을 모두 수행한다. 또한 팀 개발 환경 구축 시에 별도의 팀 서버가 없다면, 팀 개발

관리 소프트웨어(예 : 소스세이프)를 구동시키기도 한다. 반면 개발 및 테스트에만 사용되기

때문에 적은 부하만이 발생한다. 개발 서버를 사용함으로써 얻을 수 있는 이점 중 하나는

배포본을 개발 서버에 갖추고 이것을 운영 서버와 동기화 시킴으로써 애플리케이션 버전 관리를

할 수 있다는 점이다.개발 서버의 스펙은 애플리케이션 서버의 스펙과 비슷하게 구축하되 디스크와 메모리를 조금 더

설치해 주는 것이 좋다. HTTP 서비스와 RDBMS가 모두 작동되기 때문이며 각종 컴파일 및 파일

서비스, 개발팀의 문서관리 등이 모두 이 개발 서버에서 수행되는 것이 일반적이기 때문이다.많은 경우, 개발 시에 운영 서버들 중 하나를 개발 서버 대용으로 사용하는데 추가적인 유지/보수가 없다면 비용을 줄이는 방법 중 하나이다. 그러나 추가적으로 새로운 업무를 구현해야

한다거나 지속적인 유지/보수를 해야 한다면 개발 서버는 선택이 아닌 필수가 된다.

47


2.3.2.5. 개발자 PC

개발자 PC는 .NET의 주요 개발 도구인 Visual Studio.NET을 구동하기에 충분한 사양을 갖추면

되며, 하드웨어적인 요소보다는 개발자 PC에 설치되는 소프트웨어가 더욱 중요하다. 개발의

편의를 위해 개발자 PC에 웹 서버, 데이터베이스 서버를 설치해두는 경우도 많다.종류 필요소프트웨어

OS Windows 2000 Professional 이상

개발도구 Visual Studio.NET 2003 (Enterprise Developer 이상 버전을 권장)팀 개발 환경 Visual SourceSafe 6.0d 또는 기타 소스제어도구

테스트 도구 Application Center Test (Visual Studio .NET과 함께 설치됨)선택사항 IIS 5.x 이상, SQL Server 2000 Developer Edition참고로 Visual Studio .NET을 사용 시에는 512MB 이상의 메모리를 권장한다.

2.3.3. 클러스터링, 로드밸런싱 관련 기술

이 장에서는 일반적인 Clustering의 개념 및 용어에 대해서 설명하고 Windows 2000에서

제공하는 Clustering 기술에 대해서 살펴볼 것이다. Windows 2000에서 제공하는 클러스터링은

데이터 베이스 서버의 클러스터링을 위한 MSCS(Microsoft Cluster Service), 애플리케이션

서버의 클러스터링을 위한 CLB(Component Load Balancing), 웹 서버의 클러스터링을 위한

NLB(Network Load balancing)가 있다.

2.3.3.1. 클러스터링의 개념

클러스터는 단독의 System을 사용할 때보다 더욱 향상된 신뢰성(reliability), 가용성

(availability), 확장성(scalability)을 제공하기 위하여 2대 이상의 서버가 마치 하나의 서버처럼

서비스를 제공하도록 해주는 일련의 네트워크/하드웨어/소프트웨어 집합과 설정을 말한다. 클러스터는 독립 컴퓨터 그룹으로서 함께 작동하여 공통적인 응용 프로그램 집합을 실행하고

클라이언트 및 응용 프로그램에 시스템 한 대의 이미지를 제공한다. 컴퓨터들은 케이블에 의해

물리적으로 연결되어 있으며, 클러스터 소프트웨어에 의해 프로그램 방식으로 연결되어 있다. 컴퓨터들은 이러한 연결로 돌발 사고 발생 대비(failover) 조치와 로드밸런싱 기능을 사용할 수

있다.

Cluster와 관련 용어들

Farm : 하나의 사이트를 이루는 서버들(Multiple Servers)Clones : 동일하고 교체 가능한 서버들. 데이터 변경 시 모든 Clone에 복제되어진다. 소용량의

컴퓨팅 과 Static HTTP 웹 서버나 중 규모의 읽기 전용 데이터베이스와 파일 , Windows 터미널

서비스, Proxy Server등에 적용한다. 모든 clone에 동일한 응용프로그램을 사용하여 하나의

클론이 서비스를 할 수 없을 경우 다른 클론이 서비스를 함으로서 가용성(Availability)을 증대

48


시킬 수 있으며 서버의 확장 요구가 있을 경우 Clone을 추가함으로써 확장성(Scalability)를 얻을

수 있다.Partition : Data 혹은 로직 단위의 단일 서버 구성. 대용량 데이터 또는 잦은 데이터 변경이

일어나는 경우, Duplicate될 수 없는 애플리케이션에 적합하다.(Partition의 예 : Email 서버, 데이터베이스, 파일공유, 프린터 공유)Pack : Partition을 호스트하는 서버그룹. Pack내에서는 쉽게 데이터 또는 애플리케이션을

이동할 수 있다.

ClonesClones

ClonesClones

PackPack

PackPack

Front-end Web Server Farm

Application servers withBusiness logic

SQL Server databasecluster

Component routing cluster

Storage server withreplication

Network LoadBalancing

Content StagingServer

Component Load Balancing

Cluster Service

Database and file

2.3.3.2. Windows 2000 클러스터링 기술 개요

Microsoft는 시스템의 신뢰성(reliability), 가용성(availability), 확장성(scalability)을 위해서

Clustering 기술을 제공한다. Windows 2000과 Windows .NET Server는 크게 3가지의

clustering 방법이 있다. HA 구성이 가능한 서버 클러스터링 즉, Microsoft Cluster Service(MSCS), 웹 애플리케이션 서버와 같이 Object Pool, Thread Pool등의 기능을 통하여

비즈니스 로직을 구성하는 컴포넌트 사이에서의 로드 밸런싱을 가능하게 하는 컴포넌트 로드

밸런싱 클러스터 Service (CLBS), 네트워크를 통하여 요청되는 웹 기반의 애플리케이션

서비스를 위한 클러스터링 구조인 네트워크 로드 밸런싱 클러스터 Service (NLBS)의 세 가지

클러스터링 환경을 지원하여, 서비스 요청 과 비즈니스 로직의 실행 및 하드웨어 실패에 따른

서비스 환경을 모두 클러스터링 가능하게 하여 완벽한 클러스터링 인프라를 지원하고 있다.

49


Windows Cluster 기술

Microsoft Cluster Server Service(MSCS)이 서비스는 주로 응용 프로그램에 데이터베이스, 메시징 시스템 및 파일/인쇄 서비스와 같은

돌발 사고 발생 대비(failover) 조치를 지원하기 위한 것이다. 클러스터 서비스는 Windows 2000 Advanced Server에서는 2노드 돌발 사고 발생 대비(failover) 클러스터를 지원하고, Datacenter Server에서는 4노드 클러스터를 한다. 클러스터 서비스는 전자 상거래 웹 사이트

대한 데이터 저장소의 역할을 하는 Microsoft Exchange Server 또는 Microsoft SQL Server 2000 데이터베이스와 같은 중요한 업무 관련 및 기타 백엔드 시스템의 높은 사용 효율을

유지하기 위해 이상적이다.Component Load Balancing Service(CLBS)Application Center Server가 지원하는 컴포넌트 로드 밸런싱 서비스로서 여러 애플리케이션

서버에 동일하게 복제되어 있는 컴포넌트들 중 하나를 선택하여 클라이언트에게 배정해 준다. 여기서 클라이언트는 C/S 클라이언트 혹은 웹 서버가 될 수 있다. CLB는 COM+를 사용하는

middle-tier 애플리케이션 컴포넌트의 load balancing을 제공한다. CLB는 COM+ 라우터

(router)라고 불리는 서비스가 존재하여 ORB의 역할을 수행한다. 즉, 클라이언트는 항상 COM+ 라우터에게 컴포넌트 생성 요청을 하며, COM+ 라우터가 여러 애플리케이션 서버들 중에서

부하가 적은 서버를 선택하여 그 서버에서 요청된 컴포넌트가 생성되도록 유도한다. 일단

클라이언트가 컴포넌트에 대한 참조를 얻게 되면 COM+ 라우터의 관여 없이 직접 해당

컴포넌트와 상호작용 하게 된다.Network Load Balancing Service(NLBS)Windows 2000 Advanced Server와 Windows 2000 DataCenter Server에 포함된

서비스로서 네트워크 로드 밸런싱을 수행해 주는 소프트웨어이다. 높은 확장성(scalability)과

가용성(availability)을 요구하는 IP기반의 애플리케이션과 서비스를 위해 failover support(장애극복)를 제공한다. Web-tier와 front-end Services가 NLB로 적합하다.다음그림은 Windows 2000에서 제공하는 클러스터링 인프라를 그림으로 나타낸 것이다.

50


[그림 14] Windows Clustering 기법

위에서 제시한 Windows 클러스터링 기술을 함께 사용하여 확장성과 사용 효율이 높은 n계층의

사이트를 작성 할 수 있다. Front-end 웹 서버 그룹 전체에 네트워크 로드 밸런싱(NLB)을

배치하고 클러스터 서비스(MSCS)로 데이터베이스와 같은 back-end 업무 관련 응용 프로그램을

클러스터링하면, 서버 또는 응용 프로그램에 기반한 단일 오류 지점이라는 개념이 없는 거의

놀라운 확장성을 누릴 수 있다. 사용 효율이 높은 네트워킹 하부 구조를 설계하기 위한 최상의

산업 표준 방식을 함께 조합함으로써 항상 Windows 2000 기반 인터넷 사용 비즈니스를 온라인

상태에서 진행할 수 있으며 빠르게 확장하여 요구를 충족시킬 수 있다.다음 표는 각각의 응용 프로그램에서 사용해야 하는 클러스터링 기술을 보여주고 있다.

Scenario MSCS NLB BenefitsWeb Server Farm O 빠르게 용량(capacity) 확장

site downtime 최소화

Terminal Servers O 빠르게 용량(capacity) 확장server failures 최소화

File/Print ServersO

service downtime 최소화failover 후 데이터 일관성(consistency)

유지

Database/MessagingO

application downtime 최소화failover 후 데이터 일관성(consistency)

유지

51


E-Commerce Sites O O 빠르게 용량(capacity) 확장server/app downtime 최소화

다음 표는 OS와 Clustering기술에 따라 제공되는 Cluster Node 를 보여주고 있다.OS Edition Network

LoadBalancing

ComponentLoadBalancing

ServerCluster

Windows 2000 Advanced Server 32 8 2Datacenter Server 32 8 4

Windows .NET Advanced Server 32 8 4Datacenter Server 32 8 8

Windows 2000 클러스터링 기술은 다음과 같은 높은 사용 효율, 확장성 및 관리 능력을

제공한다. 향상된 가용성(High Availability): 서비스와 응용 프로그램을 서버 클러스터에서 계속

사용할 수 있게 하여 하드웨어 또는 소프트웨어 구성 요소 장애 또는 계획된 유지 보수 중에

서비스를 계속 제공할 수 있다. 향상된 확장성(Scalability): 추가적인 다중 프로세서(Windows 2000 Advanced Server는 최대 8개, Datacenter Server는 최대 32개 프로세서)와 메모리(Advanced Server는

최대 8GB, Datacenter Server는 최대 64GB RAM)로 확장할 수 있는 서버를 지원한다. 향상된 관리 편의성(Manageability) : 관리자는 단일 컴퓨터를 관리하는 것처럼 전체

클러스터 내의 장치와 리소스를 관리할 수 있다.2.3.3.3. MSCS(Microsoft Cluster Service)

MSCS(클러스터 서비스라고도 함)는 Windows 2000 Advanced Server와 Datacenter Server 서버 제품에 사용 가능한 두 가지 클러스터링 기술 중 하나이다.Windows 2000 Advanced Server에서는 2노드, Windows Datacenter Server 에서는 4노드까지 장애극복(failover) 클러스터링을 지원해 준다. 클러스터 서비스가 실행 중인 Windows 2000 및 Windows NT 기반 서버는 높은 사용 효율과 데이터 무결성을 필요로 하는 백엔드 응용

프로그램과 서비스에 대한 장애극복(failover) 조치 기능을 지원한다. 이러한 백엔드 응용

프로그램에는 데이터베이스, 파일 서버, 전사적 자원 관리(ERP) 및 메시징 시스템과 같은 기업

응용 프로그램이 포함된다.클러스터 서비스를 사용하기 위해서는 Windows 2000 Advanced Server 혹은 Windows 2000 DataCenter Server가 설치된 동일한 사양의 두 서버를 필요로 하며 반드시 두 서버는

외장 RAID 디스크를 SCSI나 파이버 채널(fiber channel)을 통해 공유해야 한다. 또한 두 서버는

클러스터를 위한 별도의 NIC 카드를 요구한다. MSCS는 두 개의 서버 즉, 2-node뿐 아니라 4-node(DataCenter Server)까지 지원한다. 그림은 SCSI 또는 fiber 채널을 통한 SCSI 방식의 공유 저장소 장치 연결을 사용하는 Windows 2000 Advanced Server 로 구성할 수 있는 2노드 서버 클러스터의 구성 요소를 보여준다.

52


RAIDDisk Sets

Private Network(heartbeats, 상태제어)

Public Network

Client PCs

Cluster Server

Node 1 Node 2Multi-initiator SCSI or

SCSI over Fiber Channel

Windows NT Server 4.0, Enterprise Edition or Windows 2000 Advanced Server

[그림 15] 2-node Clustering

각각의 응용 프로그램은 하나의 호스트에서 실행된다. 하나의 자원이 실패했을 때

응용프로그램이 정상적인 가동을 하기 위해서 다른 하나가 서비스를 지원한다. 서로간의 인식은

Heartbeat 에 의해서 하게 되며 자원모니터에 의해 resource service의 실패를 감지한다. 즉, 클러스터 서비스를 사용한 서버(데이터베이스 서버)의 클러스터링은 장애 극복(failover)을

의미하며 이것은 2대의 데이터베이스 서버를 사용하더라도 2대 모두 동일한 데이터를 제공할 수

없다는 것을 말한다. 따라서 데이터베이스 서버를 클러스터링 하더라도 성능 증가를 기대하기

어려우며, 데이터베이스 액세스가 늘어날 때 추가적인 서버 투입은 무의미 하다. 클러스터서비스는 애플리케이션의 가용성을 증대하는 것이지 성능이나 확장성과는 연관이

적으므로 처음부터 데이터베이스 서버는 충분한 Capacity(용량)을 가져야 한다. 다음그림은 Windows 2000 DataCenter Server가 지원하는 4-node Cluster를 구성을

보여주고 있다. 외장 RAID 장치를 Fiber채널에 의해 연결해 준다.

53


RAIDDisk Sets

FiberFiber--ChannelChannel

Private Network

Public Network

Windows 2000 Datacenter Server

Cluster Server

Node 1 Node 2 Node 3 Node 4

Client PCs

[그림 16] 4-node Clustering

2.3.3.4. CLB(Component Load Balancing)

Component Load Balancing(CLB)은 COM+를 사용하는 middle-tier 애플리케이션

컴포넌트의 다이나믹한 로드밸런싱이다. Server Cluster 및 NLB는 Windows 2000 Advanced Server와 Windows 2000 DataCenter Server 에서 제공되는 서비스 이지만, CLB는

Microsoft Application Center 2000(Application Center Server)를 통하여 구현된다. .NET Enterprise 서버 제품군의 하나인 Application Center Server는 Component Load Balancing의 핵심기능뿐 아니라 IIS와 Windows 2000에 구축된 웹 사이트의 컨텐츠 배포 및

관리 기능을 제공한다. 또한 NLB 기반의 클러스터를 훨씬 간단하게 관리할 수 있다. Application Center 클러스터 작성 마법사를 통해서 Windows 2000만 사용할 때 보다 더 간단하게 자동으로

NLB 설정을 구성할 수도 있다. 또한 Application Center를 통해 클러스터 내에서 서버를 쉽게

추가하고 제거할 수 있으며 온라인 및 오프라인으로 서버를 사용할 수 있다.Application Center Server를 사용하는 클러스터는 클러스터 차원의 구성 노력을 단일

콘솔에서 처리할 수 있고 통합 도구로 구성 요소와 서비스를 쉽게 관리할 수 있으므로 단일 웹

서버만큼이나 관리하기가 쉽다. Application Center Server를 사용하면 모든 웹 응용 프로그램

요소(IIS 웹 사이트, HTML 및 이미지 파일, ASP 페이지, COM+ 구성 요소 및 응용 프로그램, 데이터베이스 연결, 보안 설정, 레지스트리 설정 등)를 하나의 중앙 콘솔에서 관리할 수 있다. 시스템 관리자는 응용 프로그램이 여러 서버에 있더라도 이를 하나의 엔터티로 볼 수 있다 응용

54


프로그램을 단일 콘솔에서 업데이트하고 변경할 수 있어 대형 배열에서도 자동으로 동기화할 수

있다.

[그림 17] Application Center 가 Cluster 관리를 위해 제공하는 GUI(MMC, Command Line Interfaces)

CLB는 다음과 같은 3가지 핵심 구조를 사용하여 Component load balancing을 구현한다. CLB 소프트웨어 : load balancing기능을 제공하면 클러스터 구성원(즉, 웹

애플리케이션 서버)이 COM+ 구성 요소를 활성화하는 순서를 결정합니다. Router : 웹 서버와 웹 애플리케이션 서버 간의 message Routing을 처리한다. Router는 웹 서버(또는 별도의 서버)에 저장된 라우팅 목록을 통해서 COM+ Cluster구성원을 선별하여

요청을 전달한다. Application Server Cluster : COM+구성요소를 활성화하고 실행한다.이 application Server Cluster 는 Application Center Server에 의해 관리된다.일반적으로 웹사이트 보안을 강화하기 위해서 CLB를 사용한다. COM+ Component가 데이터를

액세스하는 수단으로 사용될 때, role-based 방식이나 programming방식의 보안 메커니즘을

사용하여 데이터를 보호한다. 만약 Component가 Web-tier에 위치할 경우에는 신뢰할 수 없는

55


클라이언트에서 오는 호출도 있을 수 있다. 따라서 CLB를 사용하면 COM+ Component를 Web-tier에서 COM+ 클러스터(Application Server)로 옮겨 이러한 문제를 해결할 수 있다. COM+ 클러스터는 일반적으로 방화벽(firewall)이 보호하고 클라이언트가 아닌 Web-Tier Cluster(Web server)에서 시작된 호출만을 받아들이게 한다. 다음 그림을 통해 더 자세히 이해 할 수 있다.

[그림 18] COM+ Cluster behind a firewall(CLB)

CLB, 즉 애플리케이션 서버 클러스터링은 데이터베이스 클러스터링에 비해 제약이 적다. 서버들이 공유해야 되는 RAID 디스크도 없으며 서버들의 사양이 동일할 필요도 없다. 다만

클러스터 내부의 서버들 사이에서 빠르게 통신할 수 있도록 클러스터 전용 NIC만이 존재하면

된다. CLB는 분산 솔루션을 작성하는 주요 기술이지만 사용할 때에는 주의가 필요하다. CLB를

사용하면 처리 속도(Throughput performance)가 떨어지지만 보안(security), 확장성

(Scalability), 손쉬운 설정(easy of Set up)을 통한 관리효율(Manageability), 로드 균형(load balancing) 조정 등의 이점이 있다. 제대로 사용하면 훌륭한 NET 기반의 솔루션을 만들 수 있다.

2.3.3.5. NLB(Network Load Balancing)

Windows 2000 Advanced Server 및 Datacenter Server 운영 체제에 들어 있는 클러스터링

기술인 NLB은 TCP/IP 기반 서비스인 Web Server, Terminal Server, 가상 사설 네트워킹

(VPN), 스트리밍 미디어 서버에 적용하기 이상적이다.

56


[그림 19] Network Load Balancing(NLB)

NLB가 제공하는 장점들은 다음과 같다. 확장성(Scalability) : 네트워크 로드 밸런싱(NLB)은 클러스터 내의 여러 서버에 해당

클라이언트 요청을 배포함으로써 웹 서버와 같은 서버 기반 프로그램의 성능을 확장한다. 소통량이 증가함에 따라 클러스터에 서버를 추가할 수 있다. 하나의 클러스터에 최대 32대의

서버를 추가할 수 있다. 고 가용성(High Availability) : 네트워크 로드 밸런싱(NLB)은 한 서버에 장애가 발생했을

때 이를 자동으로 검색하고 사용자들에게 서비스를 지속적으로 제공하면서, 10초 내에 나머지

서버들로 클라이언트 소통량을 다시 분할한다.NLB를 사용하면 들어오는 TCP 트래픽, 사용자 데이터 그램 프로토콜(UDP) 트래픽, 일반 라우팅

캡슐화(GRE) 트래픽 요청이 클러스터 서버에게 분배된다. 이 때 서버 로드 비율 설정에 기반한

통계 알고리즘에 따라 분배가 이루어진다. NLB는 클라이언트에 영향을 주지 않고

클러스터에서의 서버 추가 및 제거 작업을 자동으로 제어하여 동적인 확장을 제공한다.NLB에서 주의할 점은 IIS의 상태 관리이다. COM+의 로드 밸런싱은 COM+ 컴포넌트 자체가

상태를 갖지 않도록 코딩 되므로 별다른 문제가 발생하지 않지만 웹 애플리케이션은 사용자의 ID

57


나 쇼핑 카트(shopping cart) 등이 저장되어야 하기 때문이다. 네트워크 로드 밸런싱에서 한

사용자가 웹 서버 A에 접속한 후, 이후의 액세스가 웹 서버 B로 갈 수도 있으므로 이에 대한

주의를 기울여야 한다. 해결책은 웹 서버에 상태를 저장하지 않고, 데이터베이스 서버와 같은 제

3의 장소에 상태 정보를 저장하거나, 한 사용자는 반드시 하나의 웹 서버에만 머무르도록

설정하는 것이다.또한 가지 웹 서버 클러스터링에서 고려해야 할 사항은 여러 웹 서버들이 동일한 컨텐츠를

유지하도록 구성해야 한다는 것이다. 일반적으로 네트워크 로드 밸런싱이 사용되면 한 사용자가

어떤 웹 서버에 접속하게 된다는 것을 예측할 수 없다. 따라서 각 웹 서버는 동일한 컨텐츠를

유지하도록 컨텐츠 동기화 작업을 필요로 한다. 이러한 NLB 서비스의 컨텐츠 동기화 문제는

Application Center Server를 통해 해결할 수 있다. Application Center Server는 컴포넌트

로드 밸런싱 외에도 NLB 서비스를 지원하기 위한 기능을 포함하고 있다. 즉, 웹 서버 클러스터의

각 노드들이 동일한 HTML, ASP.NET 파일, 컴포넌트 집합을 보유하도록 Application Center Server는 동기화 작업을 수행해 준다. 개발자는 작성된 웹 애플리케이션을 클러스터 컨트롤러에

등록시켜주기만 하면 된다. 새로운 버전의 애플리케이션은 Application Center Server에 의해

적절한 시기에 각 웹 서버에 배포된다.웹 서버의 클러스터링은 NLB이외에도 L4 Switch와 같은 하드웨어를 사용하거나 DNS(Domain Name Service)를 이용하는 방법이 있다.

2.4. 팀 개발 환경

이 장에서는 엔터프라이즈 애플리케이션 개발에 필수적인 팀 개발 환경을 구축하기 위해서

고려해야 하는 여러가지 요소와 과정을 제시한다. 그리고 팀 개발 환경을 도와주는 소스 제어

도구인 소스세이프의 구성 및 사용법에 대해서 알아본다.

2.4.1. 팀 개발 모델

2.4.1.1. 팀 개발 개요

엔터프라이즈 애플리케이션은 규모가 방대하므로 개발자 혼자 작업하는 것이 아니라 다수의

개발자가 공동 개발을 하게 되는 경우가 많다. 이럴 경우, 작업 내용에 따라서 역할을 분담하여

팀을 구성해서 개발하는 것을 ‘팀 개발(Team Development)라고 한다.

2.4.1.1.1. 팀 개발의 특징

팀 개발은 일반적으로 다음과 같은 특징을 가진다. 다수의 인원이 동시에 개발하며, 각 구성원은 관리자, 개발자, 테스터 등 세분화된 역할을

가진다. 상황에 따라 역할은 중복될 수 있다. 구성원 간에 소스 또는 빌드 결과물을 참조, 공유한다.

58


소스의 백업, 버전 관리가 필요하다. 여러 단계로 세분화된 개발 프로세스를 가진다.2.4.1.1.2. 팀 개발의 문제점

팀 개발을 원활하게 이끌어 나가는 것은 쉬운 일은 아니다. 시간, 비용, 인적 유대와 같은 다양한

요소들이 존재한다. 이 중 기술적인 측면에서 팀 개발 시 발생하는 어려움들을 파악해보면 다음과

같다. 웹 애플리케이션의 경우, 한번에 개발자 한명만이 웹 애플리케이션을 호스팅하는

서버를 디버깅할 수 있다. 개발자가 각자 팀의 전체 코드를 컴파일 및 빌드하는데 시간이 과다하게 소요된다. 이로서 개발 생산성 및 효율이 저하된다.

어셈블리 간 참조가 어떤 개발자의 머신에서는 제대로 동작하나 다른 개발자에게는

동작하지 않는 경우가 있다. 전체 개발자가 작업하는 소스를 취합하여 빌드하는데 많은 시간과 노력이 소모된다. 소스 코드의 버전 관리, 백업을 하기 어렵다. 명확하게 정의된 개발 프로세스와 이를 지원하기 위한 환경이 필요하다.2.4.1.1.3. 팀 개발 문제 해결을 위한 열쇠

위에서 나열된 문제점들을 해결하기 위해서는 다음 요소들이 필요하다.반복적이며 신뢰성을 가져야 함

잘 정의된 프로세스는 단위 업무들을 세분화하여 반복적으로 수행하므로써 업무 효율성을

높여준다. 또한 버전 제어 및 빌드를 위한 전담 리소스를 두는 것이 바람직하다.신속성, 병렬 개발(Parallel Development)

공동 개발 및 빌드 환경을 구성하기 위해 소스 제어 S/W 및 별도 리소스를 사용한다. 웹

애플리케이션의 경우, 웹 애플리케이션의 특성에 맞도록 팀 환경을 구성해야 한다. 또한 소스

코드 및 프로젝트 구조를 사전에 체계적으로 정의해 놓는 것이 중요하다.

2.4.1.1.4. 팀 개발 프로세스 – High Level Life Cycle

일반적으로 애플리케이션을 개발할 때는 다음과 같은 프로세스가 존재한다. 이 프로세스는 이제

일반 애플리케이션이나 웹 애플리케이션에 관계없이 적용되는 것이 바람직하다.

59


[그림 20] 팀 개발 프로세스

업무요구사항~분석 및 설계가 주로 비즈니스 모델러(Business Modeler)의 역할이라면, 나머지

단계는 주로 개발자의 역할이 된다. 팀 개발 환경의 경우에는 구현 및 개발 과정이 하나가 아니라

여러 개의 단위로 나누어져서 동시에 병렬적으로 수행된다.개발 뿐만 아니라 이를 테스트하는 과정도 중요하다. 구현되는 각 단위는 단위별로 자기 완결적이

되도록 충분한 단위 테스트가 필요하다. 이러한 과정은 매번 전체 시스템을 테스트하는데

낭비되는 시간과 노력을 감소시켜 준다. 개발자는 각 단위를 개발하는 동시에 어떻게 테스트할

것인가를 신중하게 계획해야 한다. 개발과 동시에 테스트를 고려하면 문제점을 보다 빨리

파악해서 조치가 가능하다. 개발의 정도가 높아질수록 테스트를 통해 문제점을 파악하는 데는

더욱 오랜 시간이 걸리기 때문이다. 이렇게 처음부터 테스트를 염두에 두고 개발해 나가는 것을

테스트 우선 개발(Test-First Development)라고 부른다.개별 단위의 테스트가 성공하고, 일정한 수준까지 개발이 끝나면 전체 시스템을 테스트하게 된다. 전체 시스템을 테스트할 때는 실제 환경(Production Environment)와 동일한 환경 하에서

테스트하는 것이 중요하다.테스트가 완료되면, 프로젝트 관리자는 이를 어떻게 릴리즈 및 배포할 것인지를 결정해야 한다. 완전히 새로운 시스템인 경우에는 문제가 없지만, 이미 실행 중인 시스템(Live System)에

배포를 할 때는 신중하게 계획을 세워야 한다.

2.4.1.2. 팀 개발 프로세스 구축 순서

위에서 설명했듯이 팀 개발 문제 해결을 위한 열쇠는 반복적이고, 신뢰성 있으며, 신속한

프로세스를 구축하라는 것이다. 이러한 프로세스를 구축하기 위해서는 다음과 같은 순서를

60


따르는 것이 좋다.1. 팀 개발 환경을 구축한다.2. 팀 개발 환경을 위한 전용 하드웨어 리소스를 할당한다.3. 웹 개발 모델을 선정한다.4. 소스 프로젝트 구조를 수립하고, 이름을 부여한다.5. 빌드 프로세스를 구축한다.

이제부터 각 순서에 대해 자세히 알아보도록 한다.

2.4.1.2.1. 팀 개발 환경 구축

1.3.1.1.4에서 보았던 팀 개발 프로세스를 개발자에게 해당되는 부분만 보다 자세하게

나타낸다면 다음과 같다. 프로세스뿐만 아니라 전체를 구성하는 구성인원과 서버도 함께 나타나

있다.

[그림 21] 팀 개발 프로세스와 구성원, 서버

개발 팀

개발팀의 주 임무는 주어진 요구사항대로 애플리케이션을 개발하는 것이다. 개별 개발자는

개발을 위한 PC와 개발도구를 가지며, 데이터가 저장되어 있는 DB 서버 또는 웹 서비스 서버를

참조할 수 있는 권한을 가져야 한다. 개발자가 작성하는 코드는 소스세이프 서버를 통해 제어된다. Admin 팀

Admin 팀은 전체 프로젝트의 관리자 그룹을 지칭한다. Admin 팀은 개발 환경을 구축하고, 각

61


개발자들이 작성하는 코드를 관리하며, 작성된 코드를 취합하여 이를 빌드하는 프로세스를

수행한다. 빌드 후 테스트가 완료되면 이를 언제, 어떻게 릴리즈할 것인지를 결정하는 권한을

가진다. 테스트 팀

테스트 팀은 빌드가 완료된 결과물 패키지를 테스트 장비에 설치하고, 애플리케이션에 버그가

있는지를 파악한다. 또한 테스트 도구를 사용하여, 애플리케이션에 부하를 준 후 성능을

측정하기도 한다. 산출된 테스트 결과는 문제점을 추적하여 개발자에게 통보하거나, 실제 환경에

배포를 하기 위한 계획을 수립하는데 필요한 자료가 된다.

2.4.1.2.2. 팀 개발 환경을 위한 전용 하드웨어 리소스

위에서 설정한 환경을 지원하기 위해서는 전담 하드웨어 리소스가 필요하다. 전담 리소스는

네트워크 환경과 같은 인프라 구조(Infrastructure)와 서버 하드웨어를 의미한다. 다음은 팀 개발

환경용 인프라 구조의 예이다.

[그림 22] 팀 개발 환경용 인프라 구조

일반적인 개발 환경에 비해, 팀 개발을 위해서는 빌드 서버와 소스세이프 서버가 별도로

필요하다는 것을 알 수 있다. 그 외 개발 및 테스트를 위한 데이터베이스 서버, 웹 서버가

필요하다. 각 서버 역할에 필요한 하드웨어 및 소프트웨어 권장 사항은 다음과 같다.CPU 메모리 하드디스크

빌드서버 P3 – 600Mhz 이상 96-192MB 600MB(시스템)3GB (빌드 결과용)

소스세이프서버 펜티엄 333Mhz 이상 32-256MB 4-10GB(DB 크기 2

62


배)속도를 위해 Network Latency를 최소화할 것

데이터베이스 SQL Server 2000 Enterprise Edition웹 서버 Windows 2000 이상

IIS 5.x 이상

NTFS 파일 시스템 권장

2.4.1.2.3. 웹 개발 모델 선정

소스세이프를 사용하여 웹 애플리케이션을 개발할 때는 다음의 3가지의 웹 개발 모델 중 하나를

선택할 수 있다.Isolated 모델

각 개발자가 자신의 PC에 웹 서버를 두고 개발해 나가는 방식이다. 자신의 PC에 소스의 로컬

복사본을 가진다.Semi-isolated 모델

단일한 공용 웹 서버를 개발자들이 공유해서 사용한다. 자신의 PC에 소스의 로컬 복사본을

가진다.Non-Isolated 모델

단일한 공용 웹 서버를 개발자들이 공유해서 사용한다. 소스의 로컬 복사본은 공용 웹 서버에만

존재하며, 개발자의 PC에는 소스파일이 존재하지 않는다.

[그림 23] 웹 개발 모델

63


여러가지 모델 중에서 권장되는 것은 Isolated 모델이다. Isolated 모델이 권장되는 이유는 모든

개발자가 웹 애플리케이션의 로컬 인스턴스를 가지므로 다른 개발자에 대한 간섭없이 자유롭게

개발 및 디버깅이 가능하다는 것이다. 또한 소스세이프에서 가장 뛰어나게 지원되며, LAN에서

보다 빠르다는 장점이 있다.Semi-isolated 및 Non-isolated 모델의 단점은 웹 서버를 공유해서 사용하므로 다른 개발자를

방해하기 쉽다는 것이다. 예를 들어, 한 개발자가 디버깅을 시작하면 공용 웹 서버에 락이

걸림으로써 다른 개발자들이 웹 서버를 디버깅하거나 테스트하는 것이 불가능하다. 또한 Non-isolated 모델의 경우에는 코드 비하인드 DLL을 하나만 둘 수 있다. 그리고 FrontPage Extension의 경우, 다중 공유 체크아웃에 의한 개발을 지원하지 않는다.각 웹 개발 모델을 비교해 보면 다음과 같다.

Isolated Semi-isolated Non-isolated일반 액세스 http://localhost http://server http://server소스세이프 액세스 파일 공유 파일 공유 FrontPageUNC 액세스 필요? 예 예 아니오

Isolated동작 가능? 예 예 아니오

오프라인 지원 예 예 제한적

공용 웹 서버 아니오 예 예

웹 참조 자동 User.config 사용 자동

서버 디버깅 자동 머신당 1세션 머신당 1세션

권장사항 가장 선호됨 서버 리소스 호환 가능

2.4.1.2.4. 소스프로젝트 구조 수립

대규모 엔터프라이즈 개발 환경에서는 초기 프로젝트 구조의 수립이 매우 중요하다. 이를

위해서는 Visual Studio .NET에서 소스 파일을 관리하기 위해서 사용하는 각종 단위 및 파일의

종류에 대해서 이해해야 한다.확장자 포함가능요소 설명 및 특징

솔루션 *.sln 템플릿, 프로젝트, 폴더, 파일

최상위 컨테이너로 관련된 프로젝트를 그룹화

반드시 1개가 존재해야 함

빌드 순서를 결정하는데 사용하는 프로젝트

종속성 정보를 담음

프로젝트 *.csproj*.vbproj

폴더, 파일 어셈블리(*.exe, *.dll)를 빌드하고 이를 위한 구성

정보를 설정하는 단위

웹 프로젝트 : HTTP 경로에 생성

로컬 프로젝트 : 파일 시스템 경로에 생성

템플릿 *.etp 템플릿, 관련된 프로젝트를 그룹화하거나 정책을 적용

64


프로젝트, 폴더, 파일

프로젝트 관리자나 리더는 개발 내용을 몇 개의 솔루션과 프로젝트로 나눌 것인지를 생각해야

한다. 업무 내용에 따라서 프로젝트를 나눌 수도 있으며, 아키텍쳐 상의 계층별로 나눌 수도 있다. 또한 대규모 프로젝트에서는 이 두 가지 방법을 함께 사용하여 프로젝트를 나누어야 할 수도 있다.웹 애플리케이션의 경우, 프로젝트 구조를 더욱 더 신중하게 고려해야 한다. 웹 애플리케이션을

여러 개의 프로젝트로 나누는 것은 쉽지 않을 뿐더러 여러가지 사항을 고려해야 한다.소스 프로젝트 구조 수립에 관한 자세한 사항은 ‘2.1.2 프로젝트 생성 및 구조 수립’을 참조하기

바란다.프로젝트 관리자는 전체 애플리케이션을 프로젝트로 분할하고, 각 프로젝트에 이름을 적절하게

부여해야 한다. 이를 위해서는 적합한 명명규칙을 사전에 만들어 두는 것이 좋다. 명명규칙은

프로젝트, 어셈블리 명, 폴더 명, 네임스페이스 등을 신중하게 고려해야 한다. 기본적으로 Visual Studio .NET은 출력 어셈블리 명을 프로젝트 이름과 일치시킨다. 예를 들어

Utilities.Data.csproj라는 프로젝트를 빌드하면 Utilities.Data.dll이라는 어셈블리가 생성된다. 어셈블리의 루트 네임스페이스 역시 프로젝트 및 어셈블리 이름과 일치되게 된다. 만약 이

기본값들을 변경해야 한다면, 프로젝트 속성에서 적절하게 변경해야 한다. 그리고 소스세이프를

사용하는 경우, 소스세이프 폴더와 로컬 폴더 이름이 동일하게 사용된다.솔루션 파일은 일반적으로 단일 솔루션을 사용하지만, 마스터 솔루션 형태나 다중 솔루션으로

변형하여 사용할 수도 있다. 다음 그림은 단일 솔루션, 마스터 솔루션, 다중 솔루션을 각각 나타낸

그림이다.

[그림 24] 단일 솔루션, 마스터 솔루션, 다중 솔루션

프로젝트 규모가 그리 크지 않다면, 단일 솔루션이 가장 간편한 방법이다. 구조가 단순하므로,

65


상대적으로 구성이 쉬운 편이다. 이 경우, 참조 관계를 설정하거나 빌드를 할 때도 쉽게 수행이

가능하다.그러나, 대형 프로젝트에서는 단일 솔루션 파일만으로는 개발이 어려운 경우가 많다. 모든

프로젝트가 단일 솔루션 내에 들어있으면, 모든 개발자가 전체 프로젝트를 공유해야 한다. 프로젝트의 규모가 커질수록, 개발자가 프로젝트를 관리, 수정, 빌드하는데는 너무나 오랜 시간이

소요된다. 그러므로, 필요한 경우에는 다중 솔루션 파일을 사용하여 전체 프로젝트를 여러 개의

그룹으로 나누는 것이 바람직하다. 대신 다중 솔루션을 사용하는 경우에는 프로젝트 간의 참조

관계(종속성)를 잘 관리해야 한다. 또한 빌드 프로세스 자체가 다소 복잡해 진다는 것에 유의해야

한다.솔루션 및 프로젝트 설정이 끝나면, 실제로 이것이 저장되는 로컬 폴더 구조에도 유의해야 한다. 모든 개발자가 동일한 로컬 구조를 사용하게 하는 것이 바람직하다. 하지만 Visual Studio .NET이 기본적으로 설정하는 폴더 구조는 이러한 상황에 다소 적합하지 않다. 아래 그림의 좌측

그림이 기본적으로 설정되는 폴더 구조이다. Visual Studio .NET은 솔루션을 내 문서\Visual Studio Projects 아래에 만들며, 일반 프로젝트는 솔루션 폴더 아래에 생성된다. 그런데, 웹

프로젝트는 솔루션 폴더 아래가 아닌 IIS의 루트 디렉터리인 \inetpub\wwwroot 아래에

생성된다. 이렇게 될 경우, 솔루션 폴더 내에 관련된 프로젝트를 모두 모아 놓는 것이 아니므로, 소스 관리 시에 어려움이 따르게 된다. 그러므로 오른쪽 그림과 같이 솔루션 폴더 아래로 웹

프로젝트를 이동시켜 놓는 것이 바람직하다. 이 때 폴더를 이동시키는 것으로 모든 작업이 끝나는

건 아님에 주의해야 하다. 웹 폴더를 이동시켰을 경우, IIS에서 가상 디렉터리 설정을 변경해야

한다는 것을 잊지 말아야 한다. ‘웹 공유’ 기능을 사용하면 이를 보다 간편하게 수행할 수 있다.

[그림 25] 생성된 웹 프로젝트 위치 변경

만들어진 구조를 소스세이프에 올릴 때도 주의해야 한다. 기본적으로 Visual Studio .NET 2003은 아래 왼쪽 그림과 같이 .root를 추가하여 폴더 구조를 다시 수립한다. 이는 의도한 구조를 깨는

것이 되므로, 오른쪽 그림과 같이 다시 소스세이프 폴더 구조를 조정해야 한다. 이와 같이

66


조정하는 방법은 ‘2.4.1 소스제어 추가 시 .root가 붙게 됨’을 참조하도록 한다.

[그림 26] 소스세이프 폴더 구조 조정

2.4.1.2.5. 빌드 프로세스 구축

빌드 프로세스는 각 개발자들이 작업한 소스를 취합하여 빌드하는 과정으로 모든 팀 개발에서

가장 중요한 요소이다. 빌드 프로세스는 크게 볼 때 다음과 같은 단계로 수행된다.1. 최신 버전의 소스를 취합

2. 빌드 수행

3. 버전 별로 빌드 결과물을 정리, 보관

이러한 프로세스를 수동으로 수행할 수도 있지만, 이는 매우 번거롭고 귀찮은 일이 되므로 빌드

스크립트를 작성하여 이를 자동적으로 수행할 수도 있다. 자동화된 빌드를 수행하는 대표적인

도구로는 BuildIt .NET이 있다. BuildIt .NET은 소스세이프와 연동하여, 자동으로 최신 소스를

가져온 후 빌드 후 버전관리까지 수행해준다. 다음 그림은 BuildIt .NET이 수행하는 단계를

세부적으로 도식화한 것이다. BuildIt .NET을 사용하거나, 유사한 빌드 스크립트를 직접

작성하는 경우 또는 수동으로 작업을 수행하는 경우에도 이 단계를 참조할 수 있다.

67


[그림 27] 빌드 스크립트 단계

BuildIt .NET을 다운받거나 추가적인 설명을 보려면 다음 경로를 참조하기 바란다.http://msdn.microsoft.com/library/en-us/dnbda/html/tdlg_app.asp

2.4.2. 소스세이프 사용 가이드

2.4.2.1. 소스세이프 개요

팀 개발을 안전하고 원활하게 수행하기 위해서는 소스 제어 도구를 사용하는 것이 바람직하다. 이러한 소스 제어 도구에는 여러 가지 제품이 있으나, 여기에서는 마이크로소프트의 소스세이프

(Visual Source Safe, VSS)를 기준으로 설명하도록 하겠다. Visual Studio .NET 2003 버전에는 가장 최신의 소스세이프 6.0d 버전이 포함되어 있다. 소스세이프는 Visual Studio .NET 설치 시에 함께 설치되지 않으므로, 반드시 추가로 설치해야 한다.소스세이프가 제공하는 주요 기능은 다음과 같다.

다수의 개발자가 작업 시 소스를 보호하고 동기화한다. 버전 별로 소스를 백업 및 보관하고, 변경사항을 추적 및 병합할 수 있다. 개발자간 소스의 공유, 배포를 용이하게 해준다. Visual Studio .NET과 통합되어 개발 및 사용이 용이하다.

2.4.2.2. 소스세이프 서버 구성

팀 내에 소스 제어를 위한 서버를 두거나, 개발자의 PC 중 하나를 소스세이프 서버로 사용할 수

68

http://msdn.microsoft.com/library/en-us/dnbda/html/tdlg_app.asp


있다. 소스세이프를 설치한 후, 다음과 같은 과정을 통해 소스세이프 서버를 구성해야 한다.

2.4.2.2.1. 소스세이프 데이터베이스 생성

소스세이프를 설치하면, 기본 데이터베이스가 자동적으로 생성된다. 그러나, 이 데이터베이스를

사용하지 말고 개발 프로젝트 또는 팀 별로 별도의 소스세이프 데이터베이스를 만들어서

사용하는 것이 좋다.소스세이프 데이터베이스를 만들려면, 우선 ‘Visual Source Safe 6.0 Admin’ 프로그램을

실행한다. ‘Tools/Create Database’를 선택하면, 소스세이프 데이터베이스를 생성할 위치를

물어본다. 이미 만들어 둔 폴더를 지정하거나, 새로운 폴더를 만들어서 지정하도록 한 후, [OK] 버튼을 누르면 해당 폴더에 srcsafe.ini 파일과 하위 디렉터리가 생성된다.

2.4.2.2.2. 소스세이프 사용자 추가

데이터베이스가 만들어지면, Admin 및 Guest 계정이 존재한다. 굳이 필요가 없다면 Guest 계정은 삭제한다. 삭제하려면 해당 계정을 선택한 후 ‘Users/Delete User’를 선택한다. 또한

기본적으로 Admin 계정에는 암호가 설정되어 있지 않으므로, 반드시 ‘Users/Change Password’를 사용하여 Admin 계정의 암호를 변경하기 바란다.다음으로 ‘Users/Add User’ 메뉴를 사용하여 개별 개발자들을 위한 소스세이프 사용자를

추가한다. 반드시 개발자 별로 별도의 사용자 계정을 만들어 두는 것이 좋다. 사용자를 추가할 때, 가능한 한 사용자 이름을 해당 개발자의 Windows 계정과 동일하게 만드는 것이 좋다. 이렇게

하면 소스세이프에 접근 시 네트워크 계정과 소스세이프 계정을 비교한 후, 일치하면 자동적으로

로그인이 된다. 암호는 Windows 계정의 암호와 동일할 필요는 없다.사용자를 추가할 때, 필요하다면 읽기전용으로 지정하는 것도 바람직하다. 읽기전용으로 설정된

사용자는 소스를 볼 수는 있으나 수정할 수는 없다.

2.4.2.2.3. 공유 설정

소스세이프 사용자들이 소스세이프 서버에 접근하기 위해서는 네트워크 연결이 필요하다. 소스세이프 데이터베이스가 존재하는 폴더를 공유하면, 다른 사용자들이 소스세이프에 접근할 수

있게 된다.보다 완벽한 보안을 위해서는 공유 권한에서 Everyone을 제거하는 것이 좋다. 별도의

소스세이프 접근용 Windows 계정을 만들어서 지정하거나, 도메인 상에서 그룹을 지정하는 것이

바람직하다.공유 설정이 완료되면 각 개발자들에게 소스세이프 데이터베이스의 srcsafe.ini 파일의 공유

경로를 통보한다.

69


2.4.2.3. Visual Studio .NET에서 소스세이프 사용법

개발자들은 소스세이프에서 제공하는 Visual SourceSafe Explorer를 사용하여 소스세이프를

사용할 수도 있다. 이 도구의 사용법은 해당 도움말을 참조하기 바란다. Visual Studio .NET은

소스세이프와 완벽하게 통합되어, 대부분의 기능을 Visual Studio .NET 안에서 모두 수행할 수

있으므로, 여기서는 Visual Studio .NET을 사용하는 것을 기준으로 설명한다.

2.4.2.3.1. 소스세이프에 솔루션/프로젝트 추가

소스세이프에 솔루션 및 프로젝트를 추가하는 방법은 매우 간단하다. 추가하는 솔루션을 Visual Studio .NET에서 연 후, ‘파일/소스제어/소스제어에 솔루션 추가’를 선택하기만 하면 된다. 다음과 같은 화면이 나타나면 추가할 위치를 선택한 후 [OK] 버튼을 누른다. 이때 Project 상자에는 특별히 입력하지 않아도 된다.

[그림 28] 소스제어에 솔루션/ 프로젝트 추가

솔루션 및 프로젝트가 자동적으로 소스세이프에 추가된다. 이 때 웹 프로젝트의 경우에는 추가할

위치를 다시 물어보는 경우, 적절한 위치를 다시 지정하도록 한다. 소스세이프에 추가가

완료되면, 솔루션 탐색기에 있는 솔루션과 프로젝트 앞에 열쇠 모양의 아이콘이 붙게 된다.

70


[그림 29] 소스제어에 추가 후 솔루션 탐색기의 모습

솔루션 전체가 아닌 특정 프로젝트만을 추가하고 싶을 때는, 추가하려는 프로젝트를 선택하고 ‘

파일/소스 제어/소스제어에 선택한 프로젝트 추가’를 선택한다. 나머지는 솔루션을 추가할 때와

같은 방법으로 하면 된다.

2.4.2.3.2. 소스세이프에서 솔루션/프로젝트 가져오기

소스세이프에서 개발자의 PC로 솔루션/프로젝트를 가져오려면 ‘파일/소스제어/소스제어에서

열기’를 선택하면 된다. 다음 화면의 아래에서 가져오려는 솔루션/프로젝트가 있는 위치를

선택하고, ‘Create a new project in the folder’에 가져온 솔루션/프로젝트를 저장할 위치를

지정한다.

71


[그림 30] 소스제어에서 솔루션/프로젝트 가져오기

[OK] 버튼을 누르면 소스세이프에서 내용을 가져와서 해당 폴더에 솔루션/프로젝트가 만들어

진다. 이 때 주의해야 할 점은 웹 프로젝트의 경우, 소스세이프에서 가져올 때 기본적으로 IIS의

루트 경로(\inetpub\wwwroot) 아래에 만들어 진다는 것이다. 그러므로 사전에 솔루션을 만들

폴더 및 웹 폴더를 만들어 두는 것이 좋다. 웹 폴더는 IIS 관리자에서 가상 디렉터리를 생성하거나

일반 폴더를 만든 후 웹 공유로 설정하면 된다. 이 때 가상 디렉터리 이름(또는 웹 공유)는

소스세이프에 있는 웹 프로젝트의 이름과 반드시 일치해야 한다는 것에 주의해야 한다.

2.4.2.3.3. 소스 제어 하에서 개발

Visual Studio .NET에서 소스 제어 하에 있는 파일(솔루션, 프로젝트, 소스)을 수정하면, 자동적으로 체크 아웃이 된다. 아래 그림에서 볼 수 있듯이 체크 아웃된 파일은 붉은색 느낌표

아이콘이 붙게 된다.

[그림 31] 체크아웃된 파일

만약 해당 파일을 다른 개발자가 이미 체크 아웃했으면, 그 개발자가 다시 체크인할 때까지 체크

아웃을 할 수 없다. 다중 체크아웃을 허용하도록 소스세이프를 설정할 수도 있습니다만, 소스

동기화 시에 문제가 발생할 수 있으므로 권장하지는 않는다.해당 파일을 수정 완료했으면, 솔루션 탐색기에서 해당 파일을 오른쪽 클릭하고 ‘체크인’을

선택하여 다시 소스세이프에 체크인할 수 있다. 만약 체크아웃한 후 파일을 잘못 수정하고 저장한

경우나 체크아웃을 해제하고 싶은 경우에는 ‘체크아웃 취소’를 선택하면 된다.다른 개발자들이 수정해서 체크인한 내용이 모든 개발자들에게 자동적으로 업데이트되는 것은

아니다. 모든 개발자들은 자신의 로컬 PC에 복사본을 보유하고 있으며, 여기에 대해서 작업을

하는 것이다. 그러므로 다른 사람이 변경한 내용을 자신이 보유한 로컬 복사본에 반영을 하려면,

72


솔루션/프로젝트/파일을 선택한 후 오른쪽 클릭을 하여 ‘최신 버전 가져오기’를 선택해야 한다.

2.4.2.3.4. 기타

로컬 복사본과 소스세이프에 있는 버전을 비교하거나, 소스세이프에 저장된 버전대별 소스들을

가져와서 이전 버전으로 돌아갈 수도 있다. 또한 오프라인에서 작업을 하기 위해 연결을 끊거나, 소스세이프에 바인딩/언바인딩을 수행할 수도 있다. 이러한 세부적인 기능에 대해서는

소스세이프 도움말이나 MSDN을 참고하기 바란다.

2.4.2.4. Visual Studio .NET 2003에서 소스세이프 변경사항

아래에 기술한 내용은 Visual Studio .NET 2003에서 변경된 내용들 중 일부이며, 보다 자세한

내용은 MSDN에서 KB 820831을 참조하기 바란다.

2.4.2.4.1. 소스제어 추가 시 ‘.root’가 붙게 됨

기본적으로 소스세이프에 솔루션을 추가할 때 솔루션 명 뒤에 ‘.root’가 붙어서 생성되며, 이

하위에 솔루션, 프로젝트 디렉터리가 생기게 된다. 대신에 프로젝트를 추가할 때마다 추가할

위치를 묻는 프롬프트가 사라졌다.만약 이 동작들을 수행하지 않으려면 다음과 같이 레지스트리를 변경한다.

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl]"DoNotCreateSolutionRootFolderInSourceControl"=dword:00000001

2.4.2.4.2. 임시 파일(~sak) 없애기

소스세이프는 가용성 테스트를 위해 임시 파일(~sak)을 생성합니다. 만약 이 파일을 만들고 싶지

않다면, 다음과 같이 레지스트리를 변경합니다.

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl]"DoNotCreateTemporaryFilesInSourceControl"=dword:00000001

73


3. 개발 중 – 설계와 구현

3.1. 분석 및 설계

분석 및 설계는 요구사항을 분석하여 기능 사양을 정의한 후, 구현할 컴포넌트를 설계하는

단계이다. 이 장에서는 CBD 개발 방법론을 적용하여 .NET 개발 시에 분석, 설계를 어떻게 할

것인지에 대해서 알아본다.

3.1.1. 설계 프로세스 개요

3.1.1.1. 설계 프로세스

다음은 Microsoft의 CBD 개발 방법론인 MSF/CD(Microsoft Solution Framework / Component Design)에서 제시하고 있는 설계 프로세스이다. MSF/CD에서는 Conceptual, Logical, Physical의 세가지 단계로 설계 프로세스를 나누고 있다.

74


[그림 32] 컴포넌트 설계 프로세스

3.1.1.2. 공정표

구분 주요산출물 작업내용

Envisioning 계획 - 프로젝트 계획서

(일정, 업무 Scope 등)- 개발계획서

(개발 일정)

최적의 프로젝트 수행환경 Setting프로젝트에 적합한 계획 수립

고객의 품질 요구사항 정의

교육 MSFPlanning 업무분석/

Conceptual Design

업무 분석서

- Business Context Diagram- Workflow Diagram- Task SequenceDiagram (Optional)Use Case Scenario

기 수행중인 고객의 담당업무 파악/이해

기 운영중인 시스템의 구조 및 문제점 파악

신규 시스템의 업무기능/기술적 요소에 대한

요구사항을 체계적으로 분석

교육 적용 Tool VS.NET, ASP.NET, COM+, SQL Server 등기본 설계/Logical Design

논리 설계서

- Object 추출 및 정리

- Object 상관도

- 서비스 일반화

Pseudo Code(Optional)ERD(1차)UI Scratch

분석결과를 시스템에서 구현하고자 하는

로직으로 전환

사용자가 요구하는 특정기능과 성능을

만족시키는 프로그램으로 전환/처리 로직을

상세하게 명세화함

SA System Architecture상세 설계/Physical Design

Component 물리 설계서

- Component Interaction

Diagram- Application 구조도

- Component 정의서

ERD (2차)UI 정의서

개발자 관점에서 현실적인 제약사항을 반영한

최적의 솔루션 제시

기본 설계 결과를 시스템에서 구현하고자 하는

로직으로 전환

사용자가 요구하는 특정기능과 성능을

만족시키는 프로그램으로 전환/처리 로직을

상세하게 명세화함

Prototyping교육 코드 템플릿 및 개발 표준

75


Developing 개발 및

단위

테스트

Program Code 설계에서 작성된 프로그램 사양에 따라

실행가능한 Source code 작성

UI Spec을 토대로 각 컨텐츠 및 리소스를

적절히 배치하여 웹 페이지 작성

Source code를 대상으로 단위 프로그램이

정상적으로 실행되는지 여부를 확인하는 단위

테스트 수행

Stabilizing 테스트 및

보완

테스트 결과 및 보완내역

사용자 안내서

운영자 지침서

이행 내역서 및 프로그램

모듈들이 하나의 시스템으로 동작하게 되면서

시스템 성능과 관련된 고객의 요구사항이

완벽하게 수행되는지 확인하는 시스템 테스트

수행

개발된 시스템의 기능이 고객의 요구사항과

일치하는지 고객 주관으로 인수 테스트 실시

이행 정상 운영 및 안정화 산출물 평가 및 관련자료 최종 정리

공식적인 프로젝트의 종료를 확인하기 위해

고객으로부터 최종 인수확인서 서명 받음

최종 프로젝트 완료를 전결권자에게 보고하여

승인을 득함

3.1.2. Conceptual DesignConceptual Design 단계는 설계하고자 하는 업무에서 현재 사용자가 하는 일이 무엇이고, 비즈니스 요구사항이 무엇인지에 대해 이해하여 업무를 정의하는데 목적이 있다.Conceptual Design 단계의 주요 설계 모델 산출물은 다음과 같다.

Business Context Diagram Workflow Diagram Task Sequence Use Case Scenario Task Sequence Diagram (선택적으로 작업 수행)

3.1.2.1. 수행 절차3.1.2.1.1. Conceptual Design Research

단계 세부내용

Business Process / 사용자 그룹에 대한 조사

Business Process에 대해 조사를 한다.Business Process와 주요활동(Activities)에 대해 우선 순위

부여

76


사용자 그룹에 대한 조사

데이터 취합 면담(Interview), 프로토타이핑(Prototyping), 사용자 설문

(Survey), Help Desk 등의 기법을 이용, Business 및 사용자

요구사항을 취합한다.

3.1.2.1.2. Conceptual Design Analysis단계 세부내용

Business와 사용자 정보를

합성(Synthesis)Context, Workflow Process, Task Sequence, Physical Environment에 대한 정보를 취합

시나리오 작성 현황(As-Is) 위주의 시나리오 작성

3.1.2.1.3. Conceptual Design Optimization단계 세부내용

개선사항 반영 도출된 시나리오에 대한 개선사항(To-Be) 반영

시나리오 검증 To-Be 시나리오에 대한 검증 작업을 수행

3.1.2.2. 세부 행동 설명3.1.2.2.1. Context

구분 내용

목적 개발할 시스템을 기준으로 외부의 모든 요소들(Users, Process, System, Association)과의 관계에 대한 총체적인 View를 생성하는 것이다.

입력물 현황파악서

업무 요구사항 정의

개발업무 Scope 그룹화 (대/중/소)산출물 Business Context Diagram가이드라인 1. 선행작업으로 프로젝트에 투입된 사람들 간에 공통적으로 사용되는

용어(Data Dictionary)를 정의하도록 한다.2. 모든 외부(User, Process, System, Association)와의 상호작용을

IN-OUT의 형태로 주고 받는 내역들을 기술한다.3. System이나 Business Domain의 관점에서 내부적으로 처리해야

할 모든 일들에 해당하는 이벤트들을 포함한다.3.1.2.2.2. Workflow Process

구분 내용

목적 Business Context Diagram에서 정의한 개발할 업무의 내부 프로세스를

크게는 부서별 업무 단위부터 시작하여 Use Case 단위(한 사람이 쉬지않고

한번에 처리하는 업무단위)까지 단계를 정의하여 프로세스들을 서브

프로세스들로 Decomposition 하는 것이다.

77


입력물 현황파악서

업무 요구사항 정의

개발업무 Scope 그룹화 (대/중/소)엔터프라이즈 아키텍처(Enterprise Architecture)

산출물 Workflow Process Diagram가이드라인 1. Business Context Diagram 상에 나타난 모든 외부 요소(User,

Process, System, Association)와의 Interaction 사항을

유지하여 단위 프로세스를 기술한다.2. Decomposition 시 Level Down은 보통 3단계까지 한다.

관리 단위를 회사/부서/팀 단위로 구분하기 모호한 경우, Level Down을 대/중/소 분류로 구분후 작업을 하면 용이하다.Level Down은 보통 3단계까지 관리하는 것이 용이하고, 마지막

단계에서는 Main Actor(Initiator)가 1개만 존재하도록 한다.3. 기술하는 방법은 Decomposition과 같이 Top-Down 방식으로

작성하거나, 혹은 Bottom-Up 즉, 각 사람의 업무/일을 기술하게끔

한 후 이들 Use cases를 Assemble하고, Use cases간의 Flow를

기술함으로써 전체적인 Workflow Process Model을 완성할 수도

있으나, 일반적으로 Top-Down 방식을 이용하여 기술하면 작업이

용이하다.3.1.2.2.3. Use Case Scenario

구분 내용

목적 Workflow Process Diagram의 마지막 Level에 기술된 내용에 대하여

상세한 업무절차 및 프로세스 로직들을 기술한다. 서술적으로 풀어서

표현하는 것을 원칙으로 하고, 로직이 복잡한 경우 알아보기 쉽도록 도식화한

Task Sequence Diagram을 작성하여 이해를 도울수 있다. 이 단계에서 나온 산출물이 모든 설계의 기본이 되므로 아주 상세히, 빠짐없이 기술되도록 해야 한다.

입력물 엔터프라이즈 아키텍처(Enterprise Architecture)Business Context DiagramWorkflow Process Diagram

산출물 Use Case Scenario가이드라인 1. 사전 준비 사항, 업무 처리 절차, 사후 처리 사항으로 나누어

작성한다.2. 사전 준비 사항

업무 처리 절차가 발생하기 위한 조건을 명시하도록 한다.

78


3. 업무 처리 절차

Source로부터의 Input 항목들에 의거하여 순서에 입각한

구체적이고 명확한 비즈니스 로직을 전개한다.Use case 에 작성된 내용은 제 3자가 쉽게 이해하여 업무를 처리할

수 있을 정도, 혹은 팀별 공감대가 형성되면 잘 작성된 것이다.애매한 표현의 사용을 지양하고, 6하 원칙에 의거하여 동사와

명사를 구분하여 정확히 표현하도록 하고, 기술 시 추가적인

예외사항을 고려하고, 코드 체계 수립 등에 신경을 쓰도록 한다. - 일반적인 명사를 최대한 구분하여 기술한다. (예) 이름 -> 고객이름, 직원이름

- Workflow 에서 미처 다루지 못한 업무 절차상 예외 사항을

모두 기술한다.각각의 시나리오에서 Main Actor(Initiator)가 2개 이상이

존재하지 않도록 한다.4. 사후 처리 사항

업무 처리 절차가 마무리 되기 위한 조건 및 향후에 이루어져야 할

사항을 명시하도록 한다.

3.1.2.3. 고려사항 Logical Design 설계 시 부족한 것이 없어야 한다. 업무 절차 중 빠진 부분이 없어야 한다. 각 단위 업무 절차의 예외 처리 사항이 빠지지 말아야 한다. 현 업무 담당자의 업무 내용에 대한 확인이 필요하다. 외부 Actor의 모든 경우(Event)를 해결할 수 있는지 여부를 판단한다.(예) Business Context 및 Workflow와 Sub-Workflow에서 외부 Agent의 개수를 비교

Use Case Scenario & Workflow Process : 단위 Process(Task)에 대한 절차 단계들이

제3자가 이해하고 따라할 수 있도록 자세히 기술되어 있는가? Workflow가 쉽게 이해되도록 구성되었는가? Hierarchical Leveling 되도록 작업

Data Flow가 아닌 Work Flow가 되도록 하여야 한다.

3.1.3. Logical DesignLogical Design 단계는 프로젝트 팀 구성원의 관점에서 개념 설계에서 요구하는 서비스를

만족시킬 수 있는 솔루션을 제시하는 것이다.Logical Design 단계의 주요 설계 모델 산출물은 다음과 같다.

79


Object 추출 및 정리

Object 상관도(Interaction Diagram) 서비스 일반화

Service Generalization(일반화) Pseudo Code(선택적으로 작업 수행 : 별도의 단계로 도출 가능) Class Diagram(선택적으로 작업 수행) UI Scratch(Sketch) Logical ERD

3.1.3.1. 수행 절차3.1.3.1.1. Logical Design Analysis

단계 세부내용

Service 항목에 대한 정의 Service 항목에 대한 리스트 작성

Object 항목에 대한 정의 Object 항목에 대한 리스트 작성

Attribute 항목에 대한 정의 Attribute 항목에 대한 리스트 작성

Relationship 항목에 대한 정의 Relationship 항목에 대한 리스트 작성

3.1.3.1.2. Logical Design Rationalization

단계 세부내용

암시적 Object와 Service에 대한 조사

Implied Object와 Service에 대한 내용을 반영하고, 추가적으로 Control 항목을 도출한다.

Service 및 Object 검증 도출된 Service와 Object에 대해 검증작업을 수행한다.

3.1.3.2. 세부 행동 설명3.1.3.2.1. Object 추출 및 정의

구분 내용

목적 Conceptual Design 에서 작성된 Use Case Scenario상에서 사용된

명사들을 모두 추출하여 Object와 Attribute를 추출한다. 도출된 각

명사들은 각각 어느 Object에 소속될 것이며, 그것들에 대해 각 Object에서는 어떤 이름 (Attribute명)으로 관리될 것인지를 정한다. 이 과정을

통하여 Object, 즉 Class들이 도출된다. 또한, 도출된 Class명과 각 Class에

소속된 Attributes를 이용하여 병행적으로 DBA는 Logical ERD를 작성할

수 있다.입력물 Enterprise Architecture

Use Case Scenario

80


산출물 Object 정의(Class, Attribute)가이드라인 1. 작성된 Use Case Scenario 상에서 사용된 명사들을 모두

추출하여 아래의 양식에 모으고, 그들 명사들이 각각 어느 클래스에

소속될 것이며, 그것들에 대해 각 클래스에서는 어떤 이름

(Attribute명)으로 관리될 것인지를 정한다.2. Use Case Scenario를 기반으로 아래의 양식을 이용하여

작성한다.문서번호 UseCase

명

명사 Class명 Attribute

3. 문서 번호 : 문서번호 부여체계가 정해진 경우 문서 번호 부여체계를

따르도록 한다.예) 업무 Scope 대분류 + Sequence (01, 02, …)

4. Use Case명 : Conceptual Design에서 작성된 시나리오명을 기술

5. 명사 : Use Case Scenario의 사전, 업무 처리 절차, 사후 및

참조사항 모두에 대해서 모든 명사를 추출해서 기술한다.6. Class 명 : Use Case에서 추출된 모든 명사에 대해서 적절한 Class

명을 부여한다.너무 포괄적인 이름을 부여하지 말고, Scope에 맞게 적절히

명명한다. ‘Given Name’ + ‘대장’ or ‘담당자’를 붙여봐서

어색하지 않으면, ‘Given Name’이 Class 명으로 적절하다. ‘~관리’와 같은 용어는 너무 포괄적이어서 사용을 피하는 것이 좋다.

7. Attribute 명 : 추출된 명사의 내용에 대해 해당 Class에서

관리하는 (Field) Attribute명은 무엇인지를 기술한다.8. Object 추출 및 정리 작업에서 처음 작업하는 파일을 별도의 파일로

관리하고, 도출된 명사를 삭제하지 말고, 무엇 무엇 항목으로

변경되었다는 식으로 표현토록 한다.9. 도출된 명사를 절대로 정렬시키지 못하게 하고, 순서를 바꾸는

경우는 동일 Class 내에서만 조정하도록 할 것. (원칙은 첫 번째

작성하는 파일에서는 정렬을 하지 말도록 유도 할 것)10. 하나의 클래스에서 정의된 항목을 다른 클래스에서 사용하는

경우를 위하여 Use Case Scenario대로 명사를 도출시키고, 해당되는 클래스 명을 도출시키도록 할 것

11. 해당되는 Object 명의 Attribute 명을 결정하고, 결정된 Attribute 명을 그룹화하여 Class명을 부여하도록 한다. 문서번호, Use Case 명은 대표명만 하나 명시해도 되나, Class명은 모든 칸에

채워주도록 할 것

81


3.1.3.2.2. Object 상관도

구분 내용

목적 각각의 Use case scenario를 기반으로 Object 추출 과정에서 추출된

클래스들에게 어떠한 서비스를 요청하는 지, 클래스들 간에는 어떠한

서비스를 요청하는 지, 그리고 어떠한 내용의 서비스를 제공하는 지에 대한

상세 내용이 담기고, 각 Scenario의 업무절차별 Event 처리가 제대로

되는지 검증하고, 클래스의 Service를 도출하기 위해 사용한다.입력물 Enterprise Architecture

Use Case ScenarioObject 추출 및 정의

산출물 Object 상관도(Interaction Diagram)가이드라인 1. OID 상의 시나리오 란에는 Use Case Scenario 상의 절차를

그대로 옮겨 놓는다. (시스템화할 부분과 수작업 처리할 부분의

구분은 OID 상에서 결정한다.)2. OID의 상단에 "Object 추출 및 정의”에 나타난 해당 Use

Case/Scenario상의 Class들을 가로로 배열하여 옮겨 적는다. 유의할 사항은 메인 Actor에 관련된 클래스를 맨 앞에 둔다.

3. 시나리오상의 각 처리 절차를 대상으로, 구현하기 위해서

요구되어지는 최초의 Request로부터 그 결과를 받을 때까지의

모든 Class간 Interaction을 긴 화살표로 표시하고, 각각의 화살표

위에 적절한 Service명을 정한 후 요구되어진 서비스를 행하기

위해서 필요한 Input사항 및 Output사항을 아래의 Format으로

각각의 서비스 옆에 기술한다.(예 : Service명(요구항목1,요구항목2, 조건,...) = 요구결과리스트)

4. 요청을 받은 클래스가 제 3자에게 요청한 사람에게 응답을 주라는

형태로 Arrow-Interaction을 그려서는 안 된다. 즉, 반드시 요청

받은 자가 요청한 자에게 직접 응답을 하는 형태로 Arrow-Interaction를 그려야 한다.

5. OID는 하나의 논리적인 트랜잭션 단위이다. 사후 처리 사항도

하나의 트랜잭션 바운더리 내에서 이루어져야 할 행위이면 업무

처리 절차란에 기술한다.(예를 들어, 고객에게 무엇을 통보하거나

82

No


내역서를 출력해 주는 것과 같은 행위가 고객과의 접점에서 Sync하게 일어나야 하는 경우)

6. OID 작성 시 흔히 사용되는 서비스 명의 예는 다음과 같다.하위 서비스 : Insert, Update, Delete, Inquiry (CRUD)상위 서비스 : Register, Modify, Remove, Checkcredit, Checkbalance, Confirm, Build※ 조금이라도 Logic이 추가된 부분이 있으면, 상위 서비스명으로

명명한다.※ Build의 예 : ‘작년 실적’을 기초로 ‘올해 계획’을 생성

3.1.3.2.3. Service 일반화

구분 내용

목적 Object 추출 및 정리 단계와 Object 상관도 작업을 수행하면서 도출된

Service에 대하여 기능에 대한 통합 작업과 I/O에 사용되는 Parameter에

대한 일반화 작업을 통하여 재사용성을 높일 수 있도록 Service를

도출하는데 목적이 있다.입력물 Enterprise Architecture

Object 추출 및 정의

Object 상관도

산출물 Service 일반화(Pseudo 코드 포함 – 별도 산출물로 도출 가능)가이드라인 1. OID 내에서 각 클래스간에 화살표로 표기되었던 서비스명들을 모두

모아서 다음과 같은 양식에 종합 정리하여 각 클래스 별 Public 서비스들을 도출해 낸다.Class Service명 Input

ParameterOutput Parameter

Use Case명

2. 서비스의 성격을 파악해 보고, 유사한 서비스들에 대하여 통합된

하나의 Public Service 명을 정한다.3. 해당 서비스의 성격에 따른 일반적인 Parameter 요구사항을

생각해 보고, 이 요구사항과 현재 정의된 서비스의 Parameter 사항을 상호 비교하여 최종 Parameter In-Out 사항을 결정한다.

4. 일반화 작업 후 CRUD에 해당하는 서비스가 있는지 여부를

점검한다.-> 없는 것은 Update, Delete 등 서비스를 생성시켜준다.

5. 도출된 Class에서 Inquiry 서비스만 있는 경우

-> Main Class가 있고 Sub-Class에서 Summary성 데이터를

조회하는 경우만 생기며, 그 외는 재 고려 필요

83


6. 클래스에 대한 Ownership을 부여

(예 : Main Class 또는 Insert 하는 클래스)7. Pseudo 코드를 병행하여 표현하는 경우

”Service 일반화”에 나타난 각 Service에 대해, 그에 해당하는

Logic을 (OID를 참조하여) Use Case Scenario에서 해당 부분을

찾아서 프로그램 작성 시 로직을 이해하기 쉽게 Pseudo Code 형태로 기술한다.

3.1.3.2.4. Class Diagram (선택적으로 작업 수행)

구분 내용

목적 업무분장(Classificaiton)후 정의된 각 Class들을 기준으로 전체 Class별

그들간의 상호관계 (Interaction, Generalization, Containment)를

찾아내고, 그 관계로부터 설계작업의 합리성을 점검하는 작업이다.입력물 Enterprise Architecture

Object 추출 및 정의

Object 상관도

Service 일반화

산출물 Class Diagram가이드라인 1. “Object 추출 및 정리“ 상에 나타난 각 Class들을 Class Diagram

상에 정의한다.2. Class Diagram상에 정의된 각 Class에 대하여 “Object추출 및

정리“로부터 주요 Attribute들을 5개 이내로 옮겨 적고, “서비스일반화”로부터 나타난 모든 Service를 옮겨 적는다.

3. OID Sheet로부터 Class간의 상호관계를 찾아내어 Class Diagram상에 서로를 연결하는 긴 화살표를 그리고, 그 관계를

나타내는 적절한 이름을 각 화살표 옆에 표시한다.4. 이 때, 대개의 경우는 다음과 같이 표시할 수 있다.

-> 참조한다 : 해당 Class가 상대 Class의 정보에 대한 Read 성격의 서비스를 사용

-> 등록한다 : 해당 Class가 상대 Class의 정보에 대한 Write 성격의 서비스를 사용

-> 이용한다 : 기타 계산기의 서비스 같은 유틸리티 성격의

서비스를 사용

5. 업무의 흐름 및 Class간 상호관계로부터 그 합리성을 점검하여, 그

흐름의 조정 및 Class의 변경 그리고 빠진 Service등을 찾아

기록하고, 필요한 경우 기존 해당 산출물들에 대한 수정을 하도록

한다.

84


3.1.3.2.5. UI Scratch (Sketch)

구분 내용

목적 고객이 요구하는 비즈니스 요구사항 및 End-User의 시스템적 요구사항을

Visual하게 표현하는 것이 주요 목적이고, 이러한 작업을 통하여 Solution 개발자와의 의견 통일을 이끌어 낼 수 있다.

입력물 Enterprise ArchitectureAs-Is (현황시스템) 분석서

To-Be 설계서 (Workflow Diagram, Use Case Scenario)산출물 UI (User Interface) Scratch (Sketch)가이드라인 1. User가 사용할 화면을 정의하고 화면에서 일어나는 모든 Event를

표현한다.2. UI(화면) 간 Navigation이 표현되도록 한다.3. 1차적으로 특정 Tool에 제약을 받지 말고 화면을 도식한다.4. 2차적으로 Visual화 작업을 개발 툴을 이용하여 작성

-> 웹의 경우는 HTML로 표현

5. Logical Design 시작 시점에 작업이 이루어지도록 한다.3.1.3.2.6. Logical ERD

구분 내용

목적 Object 추출 및 정리 이후 서비스 관계를 고려하여 Entity와 Relation을

가진1차 논리적 ERD를 도출한다.입력물 Object 추출 및 정의

Service 일반화

Class Diagram (선택적으로 작업이 이루어진 경우)산출물 Logical ERD가이드라인 1. Object 추출 및 정리 자료를 DBA에게 넘겨주고, 기존 시스템과

비교하여 빠진 Attribute가 없는지 확인하여 추가하고, 추가

요청사항에서 도출 된 항목이 제대로 반영되도록 한다. 2. Database 설계 사상(정규화 등)에 입각하여 DB 기본 모델을

확정하고, DBA에게 물리적 모델을 별도 진행하도록 한다.3.1.3.3. 고려사항

Object 및 Service 이름 일반화

지정된 Object의 Service 이름이 실제 Service 내용과 직관적으로 일치하도록 사용이 되었는지

여부를 확인

Service 일반화

재사용성을 위해 서비스의 Parameter 순서 및 개수에 비종속적이도록 Parameter 일반화를

85


수행한다. Scenario 상에 반영되어 있지 않은 Attribute도 추가로 반영되어 있어야 한다.예) 예외사항, 미확정 코드 체계 등

Conceptual Design과 상호 통합되어야 한다. (Living Document)

3.1.4. Physical DesignPhysical Design 단계는 개발자의 관점에서 구현하려고 하는 Solution의 제약사항을 파악하여

실제 구현 가능한 Solution을 제시하는 데 목적이 있다.Physical Design 단계의 주요 설계 모델 산출물은 다음과 같다.

Component 상관도(Interaction Diagram) Application 구조도

Component 명세(Specification) UI 명세(User Interface Specification) Physical ERD

3.1.4.1. 수행 절차3.1.4.1.1. Physical Design Research

단계 세부내용

물리적 요구사항 파악 Infrastructure에 대한 제약사항 및 애플리케이션에 대한

물리적인 요구사항을 파악한다.PerformanceCost vs. BenefitDeploymentSupportabilityTechnologyReliabilityAvailabilityReusabilitySecurity

해결방안 모색 제약사항과 요구사항에 대한 Gap을 분석하여 해결 방안(Risk 관리)을 찾도록 한다.

3.1.4.1.2. Physical Design Analysis

단계 세부내용

예비적인 배포 모델안 수립 제안된 Network Topology 수립

제안된 Data Topology 수립

제안된 Component Topology 수립

86


예비 구현 기술 선택 예비 구현 기술에 대한 항목 정의

3.1.4.1.3. Physical Design Rationalization

단계 세부내용

패키지와 배포 전략 수립 Object를 Service-Based Component로 변경

배포 모델 수립

3.1.4.1.4. Physical Design Specification Analysis

단계 세부내용

프로그래밍 모델 수립 구현기술

Stateful vs. Stateless ObjectIn-Process vs. Out-of-Process Function CallConnected vs. Asynchronous Programming ModelThreading ModelError HandlingSecurityDistribution

컴포넌트 상세 명세 정의

3.1.4.2. 세부 행동 설명3.1.4.2.1. Component 상관도

구분 내용

목적 Logical Design에서 작성된 UI Scratch 상의 조회, 신규, 삭제, 저장 등의

이벤트들을 발생시켰을 경우, 이에 대한 서비스를 제공하기 위해 User Service/Business Service/Database Service 의 3계층에서 존재하는

컴포넌트들이 각각 어떻게 상호 작용하는 지를 파악 한다.입력물 UI Scratch

Service 일반화

산출물 Component 상관도(Interaction Diagram)가이드라인 1. 기 작성된 UI Scratch 상의 조회, 신규, 삭제, 저장 등의 이벤트들을

발생시켰을 경우, 이에 대한 서비스를 제공하기 위해 User Service/Business Service/Database Service의 3계층에서

존재하는 컴포넌트들이 각각 어떻게 상호 작용하는지를

도식화한다.

87


-> 1차와 2차로 나누어 작성하되, 1차 CID에서는 시스템 제한

사항을 고려하지 않고 단순히 각 이벤트에 대해 서비스를 제공하기

위한 컴포넌트들 간의 Interaction만을 기술

-> 2차 CID에서는 1차 CID에서 볼 수 있는 Network Topology, Data Topology, Component Topology 측면의 문제점에 대한

대책을 반영하여, 재작성

☞ Client와 Server간 Round Trip을 최소화 하도록 한다.2. 하나의 컴포넌트에서 다른 컴포넌트로 분기되는 것이 2개 이상인

경우, 분기별 Comment 필요

-> 1 : n 또는 n : 1의 경우 이벤트 구분

3. 개별적으로 2번 이상 일어나는 처리를 하나의 컴포넌트에서 받아서

일괄적으로 처리하는 경우, 또는 반대로 개별적으로 2번 이상의

처리 결과를 Subscriber에 주는 것이 아니라 하나의 공통

컴포넌트를 생성하여 한꺼번에 받아서 Subscriber에게 처리결과를

보내주도록 설계한다. 즉, 관리용 or 공통 Component 의 추가

생성 하여 활용 할 수 있도록 한다. 4. Database에 관련된 작업만 처리하는 Data Service Component

를 추가 생성 하여 활용 할 수 있다. Package의 경우 여러

Database에 대한 부분을 별도로 관리할 수 있고, 일관성 있는

방법으로 Database를 사용할 수 있다. 반면, Component Topology가 늘어나는 단점이 있다.

5. 웹 Application의 경우 UI Service 쪽에는 ASP Script 항목을

명시하고, Data Service 쪽에는 공용 DB Handling Component와 SP(Store Procedure)를 명시하고, 기타 비즈니스 로직은

Business Service에 위치시키도록 하는 방안도 고려 할 필요가

있음.(단, UI Service로 도출 항목과 구분이 되도록 표현하고, ASP Scrip로 도출될 항목도 일반 컴포넌트를 도출해 되는 방법과 Process는

동일하게 진행한다.)3.1.4.2.2. Application 구조도

구분 내용

목적 실제 미들티어(COM+)에 등록할 Application의 모습으로 업무별 연관도 및

시스템 Performance를 고려하여 Application별로 어떤 Dll 에 어떤 Class들을 정의하여 Packaging 할 것인가를 결정한다.

입력물 Service 일반화

Component 상관도

88


산출물 Application 구조도

가이드라인 1. 개발업무의 메뉴 지정에서 Sub-system 단위로 생성한다.2. Subsystem의 하위 레벨이 2 이상인 경우 분류된 최하위 업무의

상위 업무를 패키지로 생성한다.3. 애플리케이션 Packaging은 기본적으로 Out-of-process

Communication 이 최소화되도록 한다.4. 업무상 자주 Interaction이 일어나는 컴포넌트들을 모아서 하나의

애플리케이션으로 패키징하여 불필요한 마샬링을 없애도록 한다.5. Class단위로 Transaction속성을 지정하므로 Transaction이

필요한 것과 그렇지 않은 Class를 구분하여 정의한다 .6. Long-running component 들은 별도의 Class로 구분하여 다른

어플리케이션으로 패키징한다.7. 여러 어플리케이션에서 공통적으로 사용하는 컴포넌트들은

복제하여 다른 이름으로 각 서버 어플리케이션으로 등록함으로써

이를 호출한 컴포넌트가 속한 어플리케이션의 프로세스 공간에서

In-process communication 에 의한 처리가 이루어 지도록 한다.8. 애플리케이션 활성화 유형은 Server와 Library 2가지가 있다.

Server Type은 Package단위로 독립적인 프로세스(dllhost.exe)에서 실행되고, Library type은 각각 호출한 프로세스에서

실행된다.9. Dll 단위로 실제 COM+에 등록되므로 업무의 변화가 자주 일어나는

Class와 그렇지 않은 Class를 구분하여 Dll로 묶는다.-> Dll 사이즈는 500K 미만으로 한다.

10. 생성된 Application내 컴포넌트가 20개를 초과할 경우 성능과

관리의 측면을 고려하여 새로운 패키지를 생성한다. (해당 dllhost의 Memory Usage Size로 확인)

11. 한 Application의 실행 메모리 사이즈가 20MB를 넘어갈 경우

성능의 측면을 고려하여 새로운 패키지를 생성하고 컴포넌트를

분산시킨다. 12. 한 컴포넌트에 10개 이상의 Function이 발생하는 경우는 파일

사이즈의 최소화와 유지보수의 측면을 고려해 새로운 컴포넌트를

생성함을 원칙으로 한다.3.1.4.2.3. Component 명세(Specification)

구분 내용

목적 Application 구조도에서 정의된 컴포넌트에 대한 상세 내역을 Public 부분

(공개할 부분)과 Private부분(내부 로직으로 가져갈 부분)으로 나누어

89


명시하고, Pseudo 코드에서 변경된 내용을 반영하고, 구체적이고 실제적인

로직을 표현하여 개발자가 쉽게 이해할 수 있도록 표현되어야 한다.입력물 Service 일반화(Pseudo 코드 포함)

Application 구조도

산출물 Component 명세

가이드라인 1. 서비스 일반화 작업에서 1차적으로 이루어진 Pseudo Code와 ERD (2차: Physical) 산출물을 이용하여, 개발자가 이 문서만 보고도

컴포넌트를 생성시킬 수 있도록 구체화(정형화) 시킨다.2. Public 부분에는 컴포넌트에서 외부에 노출시킬 부분을 명시하도록

하고, Private 부분에는 내부적으로 처리할 부분(사전, 사후, 개별

로직..)을 명시하도록 한다. 3. 표준 Code Template(Transaction, Security, Message Queue,

Event 처리등)을 작성하여 컴포넌트 명세에 이용토록 한다.3.1.4.2.4. UI 명세(Specification)

구분 내용

목적 Final(2차) CID 기준으로 실제 사용할 UI (화면)을 작성한다. 화면 별 특이사항을 기술하여 UI 명세에 대한 이해를 돕도록 한다.

입력물 Component 상관도

Application 구조도

Component 명세

산출물 UI 명세

가이드라인 1. 1차적으로 이루어진 UI Scratch 및 이후에 이루어진 변경

요청사항을 바탕으로 UI Spec. 을 작성하도록 한다.-> 이 과정에서 Workshop or 프로젝트관련 전체회의를 하여

최종적으로 운영할 화면에 대한 Confirm을 받아야 한다.2. 웹의 경우 UI Spec. 작업에 들어가기 전에 최소한 Main

Framework 처리안을 해당 프로젝트의 Key man 에게 승인을

득해야 한다.-> Case별로 회사별 Design 규칙을 적용하는지 여부를 파악한 후

작업을 하도록 한다.3.1.4.2.5. Physical ERD

구분 내용

목적 Logical ERD 및 Physical Design 단계를 거치며 변경된 사항을 반영하여

최종적으로 확정된 ERD를 기준하여 이름, 크기등 물리 Table들의

구성요소를 완성한다.

90


입력물 Logical ERD반영된 업무 변경 사항

산출물 Physical ERD가이드라인 1. DBA가 Database 설계 사상(정규화 및 비정규화)에 입각하여 DB

모델을 확정한다.2. 해당 DB의 특성에 맞게 구성 및 조정한다.

3.1.4.3. 고려사항 물리적 제한사항(Network, Data, Application, etc)이 무엇인지 확인하고, 그리고, 이러한 사항이 Solution에 어떻게(제대로) 반영되었는지 파악

CID 상에 Client-Server간의 Round Trip수가 2번 이상이 없도록 한다. 작성된 Application 구조도를 기준으로 CID 2차에 기술된 Component간 Interaction을

Simulation하고, 다른 Application Package에 Interaction하는 (Out-of-processing)것이

있나 확인하고, 있을 경우 자주 일어나는 Case인지 아닌지 확인하여, 자주 일어나는 처리인 경우

In-processing(동일 Packaging, Library type, component 복제 등) 하도록 조정한다. Application 구조도에서 공통 컴포넌트(Admin : Control) 들이 각 Application에

적절히 등재되어 있어야 한다.-> Dispatch Manager (Dispatch + 2PC Transaction)-> Query Manager

표준 코드 Template이 제대로 작성이 되어 있고, 개발자 들이 충분히 훈련되어있는가?

3.2. 구현 – 일반 지침

이 장에서는 개발자들이 .NET 애플리케이션을 개발할 때 따라야 하는 일반적인 지침을 제시한다. 공통적으로 개발 환경을 어떻게 설정해야 하며, 개발에 들어가기 위해 프로젝트 구조를 어떻게

생성해야 하는지를 알아본다. 또한 코딩 시에 준수해야 하는 명명 규칙(Naming rule)과 주석

사용 지침에 대해서 알아본다.

3.2.1. 개발 환경 설정

여기서는. NET으로 개발을 시작하기 전에 미리 설정해야 할 초기환경에 대해 Microsoft의

개발도구인 비주얼 스튜디오 닷넷(Visual Studio .NET)를 사용하는 것을 전제로 설명한다.

3.2.1.1. 개발 PC 설정

개발 PC에 필요한 소프트웨어, 사양은 2.3.2.5 개발자 PC 를 참조하도록 한다. 설치 순서와

추가사항을 언급하면 다음과 같다.종류 소프트웨어 비고

91


운영체제 Windows 2000 SP3 이상 XP인 경우, Professional웹 서버 IIS 5.0 이상

(FrontPage Extension 포함)개발편의를 위해 개발자 PC마다 웹

서버를 설치하는 것이 좋음

개발도구 Visual Studio .NET 2003(.NET Framework 1.1 포함)

Enterprise Developer 이상을 권장

Visual SourceSafe 6.0d 팀 개발 환경 사용 시 필수

DB관련 * SQL Server 사용 시

SQL Server 2000 Developer Edition

별도의 SQL 서버가 있을 경우, 관리도구만 설치해도 무방함

* Oracle 사용 시

Oracle Data Provider for .NET(Oracle 9i Client Release2, Oracle Service for MTS 포함)

http://otn.oracle.com에서 최신버전

확인 후 다운로드

COM+ 사용시 Oracle Service for MTS도 같이 설치해야 함

데이터베이스 연결 설정 DB 관리자에게 DB 연결 방법 문의

(연결문자열, 각종 환경 설정)Oracle 사용 시 TNS 설정 필요

기타 DxFrameworkLiteDxETPLite

.netXpert 애플리케이션 프레임워크

(Lite).netXpert 엔터프라이즈 템플릿(Lite)

3.2.1.2. 운영체제별 환경 설정

ASP.NET으로 개발하는 경우, 운영체제에 따라서 몇가지 추가적인 환경 설정이 필요하므로, 다음

중 자신이 사용하는 운영체제에 맞게 필요한 환경 설정을 수행한다.

3.2.1.2.1. Windows 2000 / Windows XP Professional의 경우

Windows 2000이나 XP에서 사용하는 IIS 5.x의 경우, ASP.NET은 aspnet_wp.exe라는 별도의

Worker Process에서 구동된다. 이 때, 이 프로세스는 기본적으로 ASPNET이라는 계정으로

실행이 된다. ASPNET 계정은 ASP.NET을 수행하는 최소 권한만을 가졌으므로, 개발 시에

여러가지 제약이 많이 발생한다. ASPNET 계정에 권한을 부여하는 방법도 있으나, 실행 계정을

SYSTEM 계정으로 변경하는 것이 더욱 간편한 방법 중 하나이다. 변경을 위해서는 다음을 따라

하도록 한다. Windows가 설치된 디렉터리(C:\WINT 또는 C:\WINDOWS) 밑에서 \Microsoft.NET\Framework\v1.1.4322\CONFIG 폴더 아래의 Machine.config라는 파일을 연다. <processModel> 요소에서 username을 “machine”에서 “SYSTEM”으로 변경한다.

92

http://otn.oracle.com/


명령 프롬프트에서 iisreset을 실행하여 IIS를 재시작한다.3.2.1.2.2. Windows 2003의 경우

Windows 2003에서 사용하는 IIS 6.0의 경우, ASP.NET은 IIS에서 직접 관리되어 w3wp.exe라는 Worker Process에서 구동된다. IIS 6.0에서 ASP.NET은 NetworkService라는 계정으로

구동되는데, 이 계정 역시 최소한의 권한만을 가지고 있다. IIS 6.0의 경우, 3.2.1.2.1에서 설명한

machine.config의 <processModel>의 영향을 받지 않는다. 그러므로, 대신에 IIS관리자에서

변경해 주어야 한다. 이를 변경하려면 다음을 수행한다. [인터넷 정보 서비스(IIS) 관리]를 실행한다. 또는 명령 프롬프트에서 inetmgr을

실행한다. <응용 프로그램 풀>에서 DefaultAppPool을 오른쪽 클릭하고 <등록정보>를 선택한다. <ID> 탭에서 보안계정을 <로컬 시스템>으로 변경한 후, <확인> 버튼을 누른다.

[그림 33] IIS 6.0 에서 계정 변경

3.2.1.3. VS .NET 환경 설정

VS.NET을 이용하여 처음 개발하기 전에 기본적인 옵션들을 지정하는 것으로 사용 중에도 변경

가능하나, 작업의 일관성을 위해 사용하기 전에 지정하여 사용하도록 한다. 이러한 옵션들을 팀

전체가 동일한 환경으로 설정하면, 소스를 일관성 있게 작성하여 코드의 가독성(Readability)를

높일 수 있으며, 팀 구성원 간의 의사소통 시에 혼선을 방지할 수 있다.

93


3.2.1.3.1. 키보드 단축키 설정

VS. NET의 기본 단축키 구성이 익숙하지 않다면, 기존 Visual Studio 6 개발 IDE의 키보드

단축키 배열을 그대로 이용할 수 있다. 만약 팀 구성원이 Visual C++에 더욱 익숙하다면, 해당

키보드 매핑을 선택하기 바란다. VS .NET을 실행한 후 메뉴에서 <도구>메뉴의 옵션항목을 선택한다. <환경> 항목 중 <키보드>를 선택한 후 키보드 매핑 구성표를 Visual C++ 6로

지정한다.

[그림 34] 키보드 단축키 설정

위 방법 대신에 오른쪽과 같이 <시작 페이지>의 <내 프로필>에서 키보드 구성표를

변경해도 된다.

[그림 35] 키보드 구성표 변경

3.2.1.3.2. 탭과 들여쓰기 지정

소스의 탭 및 들여쓰기 크기를 통일하기 위한 작업이다. VS .NET을 실행한 후 메뉴에서 <도구>메뉴의 옵션항목을 선택한다.

94


<텍스트 편집기> 항목 중 해당언어의 <탭>을 선택한 후 탭 및 들여쓰기 크기를 원하는

수치로 지정한다. 기본값은 4이며, 복잡한 소스의 경우 2로 지정하는 것이 편리하다.

[그림 36] 탭과 들여쓰기 설정

3.2.1.3.3. 데이터베이스 연결 설정

개발하는 프로그램에서 사용할 데이터베이스를 참조하기 위한 작업이다. 데이터 연결을 만들면

[SQL 엔터프라이즈 관리자]와 같은 프로그램을 사용하지 않더라도, VS .NET 내에서 테이블

디자인 및 조회, 저장 프로시저 생성/수정/삭제, 뷰 디자인 및 조회와 같은 대부분의 데이터베이스

관련 작업들을 수행할 수 있다. VS .NET를 실행한 후 메뉴에서 <보기>메뉴의 서버탐색기 항목을 선택한다. <서버탐색기>의 <데이터 연결>을 마우스 오른쪽 버튼으로 선택하고, <연결 추가…>을 선택한다.

<공급자> 탭에서 사용할 공급자를 선택한다. (예 : SQL Server) <연결> 탭을 선택한 후, <서버 이름>을 입력하고 <로그온 정보>를 입력한 후 해당

<데이터베이스>를 선택한다. 이 항목은 데이터베이스의 종류에 따라 다소 달라질 수 있다.

95


[그림 37] 데이터베이스 연결 설정

<연결 테스트>를 눌러 테스트가 성공하는지 확인한 후, <확인> 버튼을 눌러서 데이터

연결을 생성한다.

3.2.2. 프로젝트 생성 및 구조 수립

3.2.2.1. 개요

엔터프라이즈 애플리케이션은 아키텍쳐를 수립할 때 다중 계층 구조로 구성을 하게 되고

전체적인 개발 규모가 큰 편이므로 프로젝트 모듈의 개수가 상당히 많아지게 된다. 따라서 실제

개발에 들어가기 전에 프로젝트 파일 및 네임스페이스의 명명 규칙 등이 확정되지 않으면, 차후에

개발 업무에서 여러가지 혼란이 발생할 수 있다.이러한 역할은 개별적인 개발자에게 맡겨 두는 것보다는 프로젝트 관리자 또는 프로젝트 리더가

결정해서, 모든 개발자가 이를 따르도록 강제하는 것이 바람직하다. 개발자들 간에는 다양한

경험과 수준의 차이가 존재하므로, 그들에게 맡겨서는 일관적이고 완성도 높은 프로젝트 구조가

나오기 어렵기 때문이다.우리가 ‘프로젝트 구조’라고 총칭하는 것은 실제로 3가지 요소를 지칭한다.

프로젝트 구조: 개발 도구 상 에서의 프로젝트 파일 구조 및 환경 설정

폴더 및 파일 구조: 디스크에 저장되는 물리적인 파일 시스템

네임스페이스 구조: 소스코드와 클래스들을 구분하기 위한 논리적인 단위

가장 바람직한 것은 이 3가지 요소들이 모두 동일한 계층 구조를 가지는 것이다. 이러한 일관된

구조는 소스 프로젝트의 전체 구조를 읽고, 이해하기 쉽게 만들어 준다. 또한 차후에 소스를 관리

및 유지 보수함에 있어서도 유리해진다.

96


유감스럽게도, VS. NET에서 제공하는 기본적인 설정으로는 이러한 구조를 일관성 있게 만드는

것이 쉽지 않다. 그러므로, 몇 가지 수작업과 다양한 방법들을 사용하여 이러한 문제를 해결해서

바람직한 구조로 만드는 것이 필요하다.

3.2.2.2. 프로젝트 계층 구조 수립 방식의 종류

프로젝트 구조를 수립하기 위한 방법은 개발 업무 단위 기준으로 나누는 방식과 애플리케이션의

논리적 계층 구조를 기준으로 나누는 2가지 방식이 있다.

<종류 1> 개별 업무 단위 기준 <종류 2> 논리적 계층 구조 기준

두 가지 방식 중 어느 것을 택할 것인가는 여러분들이 실제 프로젝트를 개발해 나가는 방식에

달려 있다. 만약 여러분의 회사가 주로 업무 단위로 개발자에게 일을 나눠주고, 한 개발자가 화면

(UI) 계층부터 데이터액세스 계층까지를 모두 개발하는 수직적 개발 모델을 택하고 있다면 <종류

1>에 제시되어 있는 개별 업무 단위 기준 방식을 택하는 것이 바람직하다. 반대로 어떤 개발자는

프리젠테이션 계층을, 어떤 개발자는 비즈니스 로직 계층을, 또다른 개발자는 데이터액세스

계층을 전담해서 개발하는 수평적 개발 모델인 경우에는 <종류2>에 제시되어 있는 논리적 계층

구조 기준 방식을 택하는 것이 좋다.통상적인 국내 SI 업체에서는 국내 환경의 특성상 화면 단위의 수직적 개발 모델을 많이

사용하므로, <종류 1>의 개별 업무 단위 기준 방식을 사용하는 것이 바람직하다. 본 문서에서는

개별 업무 단위 기준 방식을 바탕으로 설명하도록 하겠다.

3.2.2.3. 소스 프로젝트 구조 기획

개별 업무 단위 기준으로 계획한 ASP.NET 웹 애플리케이션의 소스 프로젝트 구조는 다음과 같다. 솔루션 내에 1개의 마스터 프로젝트 템플릿과 n개의 업무별 프로젝트 템플릿을 만들도록

97


구성한다.

Windows Form 기반의 프로젝트인 경우에는 웹 프로젝트를 Windows Form 프로젝트로

대치하기 바란다. 여기서는 ASP.NET 웹 애플리케이션을 기준으로 설명하도록 하겠다.

[그림 38] 소스 프로젝트 구조의 예

마스터 프로젝트 템플릿

웹 애플리케이션의 루트 디렉터리에 해당하는 마스터 웹 프로젝트와 여러 개의 공통 컴포넌트

프로젝트로 구성된다.마스터 웹 프로젝트는 IIS에서 생성되는 가상디렉터리로 매핑되며, 웹 애플리케이션 속성이

지정되어 있다. 또한 web.config 설정 및 Global.asax를 가진다. 웹 애플리케이션 내에 속하는

모든 웹 프로젝트는 이 설정들의 영향을 받는다.공통 컴포넌트 프로젝트는 마스터 프로젝트 템플릿 및 업무별 프로젝트 템플릿에 속한 모든

프로젝트들이 공유하는 컴포넌트들을 정의하는 곳이다. 업무별 프로젝트 템플릿

업무별 프로젝트 템플릿은 웹 애플리케이션을 여러 개의 기능 부분으로 나누었을 때 그 중 부분

하나를 구현하는 단위로, 하위 웹 프로젝트와 Business Rule 프로젝트, DAC 프로젝트로

구성된다.하위 웹 프로젝트는 웹 애플리케이션 디렉터리 아래의 하위 디렉터리에 해당한다. 각종

애플리케이션 속성은 루트 디렉터리의 설정을 상속한다. Business Rule은 비즈니스 규칙

컴포넌트를, DAC은 Data Access 컴포넌트를 정의하는 곳이다.

98


위의 내용을 바탕으로 실제로 생성할 솔루션, 템플릿, 프로젝트 명, 프로젝트 종류, 네임스페이스를 확정한다. 다음은 NorthwindSolution이라는 솔루션을 구성한 예이다.

[그림 39] 소스 프로젝트 구조의 예

3.2.2.4. 실제 프로젝트 생성

소스 프로젝트 구조 기획 에서 정의한 프로젝트 구조에 맞게 실제 솔루션, 템플릿, 프로젝트를

생성하고, 사전에 만들어진 프로젝트 또는 소스를 프로젝트 내에 추가한다.실제로 이러한 프로젝트를 생성하는 작업은 매우 번거로운 작업이므로 DxFrameworkLite 내의

엔터프라이즈 템플릿을 사용하면 간편하게 자동으로 생성할 수 있다. 여기서는 이를 수동으로

생성하는 방법에 대해서 설명하도록 한다.각 프로젝트를 생성한 후에는 명명 표준에 맞게 프로젝트의 기본 네임스페이스 및 어셈블리

이름을 반드시 수정하도록 한다. 해당 프로젝트를 오른쪽 클릭 후 <속성>을 선택하고, <공용속성-일반>에서 응용 프로그램 항목에서 수정하면 된다.하나의 ASP.NET 애플리케이션을 여러 개의 프로젝트로 쪼개는데는 다소의 노우하우가 필요하다. 이를 위해서는 다음과 같은 방법을 따르기로 한다.

3.2.2.4.1. 솔루션 생성

VS .NET의 <파일> 메뉴에서 <새로 만들기> 와 <빈 솔루션>을 선택한다. 솔루션 이름은 통상

명명표준에 따라 정해진 개발 프로젝트 명을 사용하며, 솔루션을 만들 위치를 선택한 후 <확인> 버튼을 누른다.

3.2.2.4.2. 마스터 프로젝트 템플릿 생성

마스터 프로젝트 템플릿을 생성한다. 솔루션 탐색기에서 솔루션을 마우스 오른쪽 버튼

클릭 후 <추가>, <새 프로젝트>를 선택한다. <기타 프로젝트/엔터프라이즈 템플릿 프로젝트>에서 <엔터프라이즈 템플릿 프로젝트>를 선택한다. 마스터 프로젝트 템플릿의 이름은 통상 솔루션 명과 동일하게 고, 솔루션과 같은

99


위치를 선택한다.

[그림 40] 마스터 프로젝트 템플릿 추가

3.2.2.4.3. 마스터 프로젝트 템플릿에 프로젝트 추가

마스터 웹 프로젝트를 생성한다. 프로젝트 순서는 반드시 다음을 따르도록 한다. Windows 탐색기에서 솔루션을 만든 폴더(예:NorthwindSolution) 아래에 폴더를

생성한다. 폴더의 이름은 마스터 웹 프로젝트로 사용할 이름을 입력하도록 한다. (예:Northwind) 폴더 등록정보의 <웹 공유> 탭에서 <이 폴더를 공유함>을 선택하고 <확인>을 누른다. 이렇게 하면, 기본 웹 사이트에 해당 이름의 가상 디렉터리가 생성된다. (예: http://localhost/Northwind) 생성된 디렉터리는 웹 애플리케이션 속성을 가진다.

[그림 41] 웹 공유를 통한 가상 디렉터리 생성

100


VS .NET의 <솔루션 탐색기>에서 마스터 프로젝트 템플릿을 오른쪽 클릭 후, <추가>-<새

프로젝트>를 선택한다. <ASP.NET 웹 응용 프로그램>을 선택하고, 위치를 위에서 만든 웹 공유의

URL(예: http://localhost/Northwind)로 지정한다. 이와 같이 폴더를 먼저 만들고 웹 프로젝트를

생성하는 이유는, 그냥 웹 프로젝트를 생성하면 디폴트로 wwwroot 아래에 만들어 버리기 때문이다.

[그림 42] 마스터 웹 프로젝트 추가

Common이라는 웹 프로젝트를 추가한다. Common은 마스터 웹 프로젝트의 하위에 생성되며, 공통적으로 사용되는 웹 요소(이미지, CSS, 자바스크립트, HTC, 웹 폼 등)들을 모아놓기 위한

곳이다. Common 프로젝트는 다음 순서로 추가한다. VS .NET의 <솔루션 탐색기>에서 마스터 프로젝트 템플릿을 오른쪽 클릭 후, <추가>-<새 프로젝트>를 선택한다. <빈 웹 프로젝트>를 선택하고, 위치를 위에서 만든 마스터 웹의

URL 아래(예: http://localhost/Northwind/Common)로 지정한다. “인터넷 정보서비스 관리자”에서 Common의 등록정보를 열고, <응용프로그램 설정>에서 <제거> 버튼을 눌러서 애플리케이션 속성을 제거한다. 이렇게 해야 Common이 마스터 웹

프로젝트와 동일한 하나의 웹 애플리케이션으로 묶이게 되며, 구성 정보 및 세션 등으로 공유할

수 있게 된다.

101


[그림 43] 하위 웹의 응용프로그램 속성 제거

Common 프로젝트에서 생성되어 있는 Global.asax, machine.config 파일을 삭제한다.

<솔루션 탐색기>에서 마스터 웹 프로젝트를 오른쪽 클릭하고 <참조 추가..>를

선택한다. <프로젝트> 탭에서 Common 프로젝트를 선택한 후, <선택> 버튼을 누르고, <확인>을 누른다. 프로젝트 참조를 걸면, 마스터 웹 프로젝트의 /bin 디렉터리 내로 Common 프로젝트의 출력 어셈블리(*.dll)가 자동 복사되므로 편리하다.

102


[그림 44] 프로젝트 참조 추가

필요에 따라서 공통 컴포넌트 프로젝트를 추가한다. 여기서는 ApplicationFramework, Common.Data, WebControls라는 3개의 프로젝트를 추가하는 것으로 하겠다.

VS .NET의 <솔루션 탐색기>에서 마스터 프로젝트 템플릿을 오른쪽 클릭 후, <추가>-<새

프로젝트>를 선택한다.다음과 같은 이름과 위치를 사용하도록 권장하며, 프로젝트 템플릿은 <클래스 라이브러리>를

선택한다. 위치가 없을 경우, 해당 폴더(\Projects\BaseProjects\)를 생성하도록 한다.이름 위치 설명

ApplicationFramework 솔루션디렉터리\Projects\BaseProjects\

각종 Base 클래스, 유틸리티 클래스

Common.Data 솔루션디렉터리\Projects\BaseProjects\

Typed DataSet들을 집적

WebControls 솔루션디렉터리\Projects\BaseProjects\

사용자 지정 웹 폼 컨트롤

(Optional)

3.2.2.4.4. 업무별 프로젝트 템플릿 생성

업무별 프로젝트 템플릿을 생성한다. 솔루션 탐색기에서 솔루션을 마우스 오른쪽 버튼

클릭 후 <추가>, <새 프로젝트>를 선택한다. <기타 프로젝트/엔터프라이즈 템플릿 프로젝트>에서 <엔터프라이즈 템플릿 프로젝트>를 선택한다. 업무별 프로젝트 템플릿의 이름은 통상 <업무명> + “Projects”(예: OrderProjects)로 명명한다. 위치를 반드시 솔루션디렉터리\Projects로 변경해야 한다는 것에

주의한다.

[그림 45] 업무별 프로젝트 템플릿 추가

103


3.2.2.4.5. 업무별 프로젝트 템플릿에 프로젝트 추가

업무명(예: Order, Product)으로 하위 웹 프로젝트를 생성한다.업무별 프로젝트 템플릿 아래에 추가한다는 것을 제외하고는 2.1.2.4.3의 Common 프로젝트

추가 시와 동일하게 작업한다. 업무별 프로젝트 템플릿 아래에 Business Rule 프로젝트를 추가한다.프로젝트의 명칭은 명명 규칙을 따르며(예: Northwind.Order.biz), 클래스 라이브러리로

선택한다. 업무별 프로젝트 템플릿 아래에 DAC 프로젝트를 추가한다.프로젝트의 명칭은 명명 규칙을 따르며(예 Northwind.Order.dac), 클래스 라이브러리로

선택한다.

프로젝트를 추가한 후에는 프로젝트의 각종 속성(출력 어셈블리명, 기본 네임스페이스 등)을

알맞게 수정해야 한다는 것에 유의한다. 또한 필요한 경우 프로젝트 간 또는 특정 어셈블리에

대한 참조를 걸어야 한다는 것도 잊지 말아야 한다.

3.2.2.5. 프로젝트 구조 생성 결과

위 과정들을 거쳐서 최종 생성된 솔루션 및 프로젝트와 실제 폴더 구조는 다음과 같다. VS .NET의

프로젝트 구조와 실제 폴더 구조를 대비시켜 보기 바란다.

[그림 46] 프로젝트 구조 생성 결과

104


3.2.3. 명명 규칙(Naming Rule)여기에서는 분석 설계 단계의 산출물과 구현 단계에서 코드 작성 시에 적용할 명명 규칙을

설명한다. 이러한 규칙을 준수하여 작성함으로써 프로젝트 참가자 사이에 원활한 의사소통이

가능하게 되며, 각 단계별 산출물 사이에 일관성을 유지할 수 있다.

3.2.3.1. 일반 사항

다음은 명명 규칙에 공통적으로 적용되는 일반적인 사항이다. 업무 영역에 적합하게 정의된 용어를 사용한다. 같은 유형에 명명할 때, 비슷한 명칭이나 대소문자만 다른 명칭 사용을 삼가한다.3.2.3.1.1. 대소문자 혼용

여러 개의 단어로 구성된 이름의 경우, 명칭의 가독성을 높이기 위해 대소문자를 적절히

혼용한다. 대소문자 혼용 시에는 다음 중 방법 중 하나를 사용한다.유형 설명 예 적용대상

Pascal Case

모든 단어의 첫번째 글자를

대문자로 쓴다.BackColor 클래스, 열거형, 열거값, 이벤트,

읽기전용 정적 필드, 인터페이스, 메서드, 네임스페이스, 속성 등

Camel Case

맨 첫번째 글자는 소문자로, 나머지 각 단어의 첫번째

글자를 소문자로 쓴다.

backColor 매개변수(parameter)인스턴스 필드(instance field, 클래스 변수)

Uppercase

모든 글자를 대문자로 쓴다. System.IO 2글자 정도의 단어, 상수

3.2.3.1.2. 약어 사용을 자제

가능한 한 모호한 약어 대신에 단어 전체(full 영단어)를 사용하는 것이 좋다. 이렇게 하면

코드의 가독성과 변수의 의미를 알기 쉽게 된다.예 : TmEmpMgt (X) - TempEmployeeManagement (O)

명칭이 지나치게 길어질 때는 약어를 적절히 사용한다. 약어를 사용 시에는 일반적으로

통용되는 약어이거나, 사전에 정의된 약어를 사용한다.예 : Temporary -> Temp, Information -> Info, UserInterface -> UI, Number -> No

약어 사용 시 2글자까지는 Uppercase를, 2글자를 넘어갈 때는 Pascal 또는 Camel Case를 사용하는 것이 좋다.예 : System.Web.Ui (X) - System.Web.UI (O), HTMLButton (X) – HtmlButton (O)3.2.3.1.3. 단어의 선정

업무 영역에 적합하게 정의된 용어를 사용한다. 같은 유형에 명명할 때, 비슷한 명칭이나 대소문자만 다른 명칭 사용을 삼가한다.

105


자주 사용되는 .NET Framework의 네임스페이스와 중복되지 않도록 한다. 또한 .NET Framework 및 각 언어에서 사용하는 키워드와 중복되지 않아야 한다.

3.2.3.2. 네임스페이스 명명 규칙

.NET에서는 클래스를 논리적으로 그룹화하기 위해 계층화된 네임스페이스(Namespace)를 통해

분류한다. 그러므로, 사전에 체계적으로 네임스페이스를 잘 정의해두는 것이 필수적이다. 네임스페이스의 예는 다음과 같이 회사명, 기술-제품명, 하위제품명, 기능 등을 마침표(.)를 통해

구분한다. 이때, 각 이름은 Pascal Case를 사용해야 한다.

Microsoft.Office.Word.Design본 표준에서는 업무용 시스템에 맞게 다음과 같은 네임스페이스 구조를 따르기를 권장한다.

수준 내용 고정값 / 예제 생략가능

1 회사명 NETXPERT X2 도메인 / 부서 Consulting O3 애플리케이션/시스템 명 SampleApp X4 하위 시스템 SpecInfo O5 논리적 계층 Biz O

NETXPERT

도메인/부서명

시스템 약어

서브시스템1 서브시스템2 서브시스템3 서브시스템4bizdacweb

위 내용을 기준으로 작성된 네임스페이스의 예는 다음과 같다.

NETXPERT.Consulting.SampleApp (회사명.부서명.시스템명)NETXPERT.SampleApp (회사명.시스템명 -> 부서명 생략)NETXPERT.Consulting.SampleApp.SpecInfo.Biz (회사명.부서명.시스템명.하위시스템명.논리적계층명)

106


3.2.3.3. 클래스 명명 규칙 클래스 이름에는 명사 또는 명사구를 사용한다. Pascal Case를 사용하며, 약어는 꼭 필요한 경우에만 사용한다. MFC 스타일처럼 클래스를 나타내는 C 등의 접두사를 사용하지 않는다.(예 : CFileStream (X) – FileStream (O)

클래스의 성격에 따라 접두사나 접미사를 적절히 사용한다.

다음은 본 표준에서 권장되는 클래스 명명 규칙이다.구분 명명 표준 예제

Base Class 공통기능명 + Base RuleBase, DacBaseBusiness Façade

[Use Case Group명] + System/Façade/Service

ProductSystem, OrderService

Business Rule 트랜잭션 사용 : [Use Case Group명] + _Tx EmployeeInfo_Tx트랜잭션 미사용 : [Use Case Group명] + _NTx

EmployeeInfo_NTx

Data Access [Table명] + _Dac AHPEMP_DacTyped DataSet ds + [Table명] dsAHPEMPException Class [사용자정의예외명] + Exception BusinessRuleException

3.2.3.4. 인터페이스 명명 규칙 인터페이스 이름은 문자 I를 접두사로 사용하여 인터페이스임을 표시

예 : IServiceProvier, IComponent 나머지는 클래스 명명 규칙과 동일

3.2.3.5. 메서드 명명 규칙 메서드 이름에는 동사 또는 동사구(동사 + 명사)를 사용한다. Pascal Case를 사용한다. CRUD 동작의 경우, Business Logic이나 Data Access 계층의 클래스 메서드는 사전에

약속된 동사를 사용한다. Business Logic은 동사 + 명사의 조합을, Data Access는 동사만을

사용한다.작업구분 Business Façade / Rule Data Access추가 Add/AddNew/Append/Register + 명사 Insert수정 Modify/Change/Update + 명사 Update삭제 Remove / Delete + 명사 Delete조회 Get / Inquire + 명사 Select / Inquire

107


Get / Inquire + 명사 + By + 조건(Optional) 동사 + 명사가 될 경우, 상황에 따라 명사는 복수형을 사용하도록 한다. Data Access에서 Insert/Update/Delete/Select는 일반적으로 오버로딩하여 기본적인

메서드명을 사용하도록 한다. 단, 상대적으로 경우의 수가 많은 Select 메서드의 경우 예외적으로

이 규칙을 무시할 수 있다(SelectBy[조건] 등을 허용할 수도 있음).3.2.3.6. 열거형(Enum) 명명 규칙

열거형 type 및 값의 이름에는 Pascal Case를 사용한다. 약어는 꼭 필요한 경우에만 사용한다. 열거형 type 이름에 Enum 접두사를 사용하지 않는다. 대부분의 열거형 type에 단수형 이름을 사용하지만, 비트 필드의 경우 복수형 이름을

사용한다. 비트 필드 Enum 형에는 항상 FlagsAttribute를 추가한다.

3.2.3.7. 변수 및 필드 명명 규칙 변수 이름은 짧으면서도 의미가 있는 단어를 사용한다. 형식은 명사 또는 명사구를

사용한다. 헝가리안 표기법은 가급적 사용하지 않는다. 루프 카운터(loop counter)를 제외하고는 가급적 모호한 이름(a, i, j, s 등)을 사용하지

않도록 한다. 특히 메서드의 매개변수는 매개변수의 이름과 type을 통해 매개변수의 의미를

확인할 수 있을 정도로 설명적이어야 한다. 필드(멤버변수)에 m_와 같은 접두사를 사용할 필요는 없다. 그러나 편의상 _등을

사용하여 구분하는 것이 좋을 때도 있다. 매개변수, 지역 변수 및 인스턴스 필드(instance field)의 경우에는 Camel Case를

사용한다. 정적 필드(static field)의 경우에는 Pascal Case를 사용한다. UI 컨트롤의 경우, DataPack에 바인딩 시에 RequestInfo 클래스를 사용하려면 UI 컨트롤 필드의 이름을 데이터베이스의 필드명과 동일하게 선언해야 한다.

3.2.3.8. 상수(Constants) 명명 규칙 상수는 모두 대문자(Uppercase)를 사용한다. 단어와 단어 사이는 _로 연결한다.

예) int MAX_WIDTH = 400;

3.2.3.9. 속성(Property) 명명 규칙 속성 이름은 명사 또는 명사구를 사용하며, Pascal Case을 사용한다. 헝가리안 표기법을 사용하지 않는다.

108


속성을 만들 때는 내부 type과 같은 이름을 사용한다. 예를 들어, Color라는 속성을

선언하는 경우 해당 속성의 type도 마찬가지로 Color이어야 한다. Private 인스턴스 필드를 노출하는 경우, 속성명은 인스턴스 필드의 Camel Case를

Pascal Case로 전환하여 사용한다.*VB.NET의 경우, 내부 type의 명명법은 속성명 앞에 m_ 를 붙인다.

public class MyClass {private int itemCount;public int ItemCount { get { … } set { … }}}

Public Class [MyClass]Private m_ItemCount as IntegerPublic Property itemCount() as Integer

Get…End GetSet(ByVal Value as Integer)…End Set

End PropertyEnd Class

3.2.3.10. 이벤트 명명 규칙 Pascal Case를 사용하며, 헝가리안 표기법을 사용하지 않는다. 이벤트 처리기 이름에는 EventHandler 접미사를 사용한다. sender와 e라는 두 개의 매개변수를 지정한다. 이벤트 인수 클래스의 이름을 지정할 때는 EventArgs 접미사를 사용한다.

예 : public delegate void MouseEventHandler(object sender, MouseEventArgs e);Public Delegate Sub MouseEventHandler(ByVal sender as Object, ByVal e as MouseEventArgs)

시점을 나타낼 경우, BeforeXxx / AfterXxx 대신 ~ing / ~(e)d를 사용한다.

예 : BeforeClose, AfterClose (X) – Closing, Closed (O)

109


3.2.4. 주석 사용 지침

일반적으로 코드만 가지고는 정확하게 코드가 의미하는 바가 무엇인지 이해하기 힘들다. 주석

(Comment)은 코드에 추가적인 설명을 달아서 코드를 보다 읽기 쉽게 만들어 준다. 여기에서는

개발자들이 준수해야 하는 주석 사용 지침을 설명한다.

3.2.4.1. 일반 사항 코드에 장식을 하지 않는다(배너식의 주석 사용을 자제한다). 주석은 가능한 한 단순하게 한다. 코드 작성 이전에 주석부터 작성한다. ‘무엇이 되었다’가 아니라 ‘무엇이 이러한 이유로 이렇게 되었다’ 식으로 작성한다. 주석 위치는 클래스의 시작, 각 메서드 선언의 바로 위에 한다. 메서드 내부에서도 단계별로 구분지어서 설명할 필요가 있을 때도 주석을 달도록 한다. 변수 하나의 의미를 쓰는 주석 등은 사용하지 않는다. 변수 이름을 명확하게 주어서

주석을 달 필요를 없애도록 한다.3.2.4.2. C# 주석 포맷

C#에서는 주석을 달기 위한 다양한 포맷을 제공한다. 그 중 XML 주석을 필수적으로 사용하도록

권장하며, 나머지 주석은 개발자의 편의에 따라 달도록 한다.

3.2.4.2.1. 단일 라인 주석

//로 시작하며, 해당 라인의 끝까지 적용된다. 설명하고자 하는 코드의 바로 윗줄이나, 코드와 같은 라인의 오른쪽에 작성한다. 하나의 라인이나 한 라인의 일부를 주석처리해서 컴파일되지 않도록 임시로 막을 때도

사용된다.

if ( foo > 1) {// 해당 작업을 수행

…}ElseReturn false; // 수행할 작업이 없으므로 종료

// obj.DoSomething();

3.2.4.2.2. 블록 주석

/*로 시작하여 */까지 적용된다. 한줄 또는 여러 줄을 주석처리하거나, 코드의 블록이 컴파일 되지 않게 임시로 막을 때도

110


사용된다.

if (condition) {/* TODO : 해당 조건을 처리하는

루틴을 여기에 작성해야 한다.*/}

3.2.4.2.3. XML 주석

/// (단일라인) 또는 /** */ (블록)을 사용하며, XML 태그를 사용하여 주석을 달 수 있다. XML 주석을 사용하면, 컴파일 시 소스코드에서 XML 문서를 만들어 내거나 VS.NET의

[주석 웹 페이지 빌드] 기능을 사용하여 HTML 문서를 생성할 수 있다. 사용자 정의 형(클래스, 위임, 인터페이스) 또는 멤버(메서드)의 바로 앞에 사용한다. 이

항목들은 반드시 XML 주석을 작성하도록 한다. VS.NET에서는 코드 편집창에서 주석을 달려는 사용자 정의 형이나 메서드 바로 위에 ///를 입력하면, 대상에 적합한 XML 주석 태그가 자동적으로 삽입된다.

3.2.4.3. 소스코드 주석 권장안

C# 개발 시 다음과 같이 주석을 다는 것을 권장한다.

/*ProductInfo_NTx.cs : 제품정보검색 클래스 정의

NETXPERT.Consulting.SampleApp.Biz.ProductInfo_NTxVersion 1.1Made by : [email protected] : 2004-05-10Last Update : 2004-05-14*/

…

/// <summary>/// ProductInfo_NTx : 제품 정보 검색 클래스

/// </summary>public class ProductInfo_NTx {…/// <summary>/// 제품 정보를 조회합니다.

111


/// </summary>/// <param name=”datapack”>검색조건</param>/// <param name=”totalCount”>전체 데이터 개수</param>/// <returns>dsProduct</returns>public dsProduct GetProducts(DataPack dataPack, out int totalCount) {…}

3.2.4.4. VB.net 주석 포맷

VB.net 주석은 기존의 VB에서와 동일한 방식을 제공한다. 또한 C#과 같은 XML 주석을 달아, 코딩에 대한 문서 작업시 혹은 클라이언트에게 빌드된 어셈블리를 제공할 때 보다 생산성 높은

개발을 할 수 있도록 인텔리센스를 지원해 준다.

3.2.4.4.1. 단일 라인, 블록 주석

단일 라인 주석의 경우 (‘) 혹은 REM 을 붙이고, 블록 단위 주석의 경우 각각의 코딩라인

앞에 (‘) 을 붙인다

REM obj.DoSomething()혹은

’ obj.DoSomething()

3.2.4.4.2. XML 주석

XML 주석을 사용하면, 컴파일 시 소스코드에서 XML 문서를 만들어 내거나 VS.NET의

[주석 웹 페이지 빌드] 기능을 사용하여 HTML 문서를 생성할 수 있다. 사용자 정의 형(클래스, 위임, 인터페이스) 또는 멤버(메서드)의 바로 앞에 사용한다. 이

항목들은 반드시 XML 주석을 작성하도록 한다. VB.net의 경우, 기본적으로 XML 주석을 지원하지 않는다. 이를 지원하기 위해서는

별도의 Add-In을 설치해야 한다. 해당 Add-In은

VBCommenter(http://www.gotdotnet.com/workspaces/releases/viewuploads.aspx?id=112b5449-f702-46e2-87fa-86bdf39a17dd) 에서 다운로드 받을 수 있다.

VS.NET에서는 코드 편집창에서 주석을 달려는 사용자 정의 형이나 메서드 바로 위에 (‘ ‘ ‘)를 입력하면, 대상에 적합한 XML 주석 태그가 자동적으로 삽입된다.

3.2.4.5. 소스코드 주석 권장안

VB.net 개발 시 다음과 같이 주석을 다는 것을 권장한다.

''' -----------------------------------------------------------------------------

112

http://www.gotdotnet.com/workspaces/releases/viewuploads.aspx?id=112b5449-f702-46e2-87fa-86bdf39a17dd

http://www.gotdotnet.com/workspaces/releases/viewuploads.aspx?id=112b5449-f702-46e2-87fa-86bdf39a17dd


''' ProductInfo_NTx.cs : 제품정보검색 클래스 정의

''' NETXPERT.Consulting.SampleApp.Product.Biz.ProductInfo_NTx''' Version 1.1''' Made by : [email protected]''' Created : 2004-05-10''' Last Update : 2004-05-14''' -----------------------------------------------------------------------------''' <summary>''' ProductInfo_NTx : 제품 정보 검색 클래스

''' </summary>''' <remarks>''' -----------------------------------------------------------------------------Public Class ProductInfo_nTx

''' -----------------------------------------------------------------------------''' <summary>''' 제품 정보를 조회합니다.''' </summary>''' <param name="Param">검색조건</param>''' <returns>DataSet</returns>''' -----------------------------------------------------------------------------Public Function GetProduct(ByVal Param As String) As DataSet

.....End Function

End Class

3.3. 구현 – 프로그래밍 지침

이 장에서는 실제로 코드를 작성할 때 따라야 하는 프로그래밍 지침을 알아보도록 한다. 프로그래밍 지침의 내용은 이전에 계획된 애플리케이션 아키텍처와 분석 및 설계를 기반으로

설명하도록 하겠다.

3.3.1. 개요

애플리케이션 아키텍처와 설계 단계를 거쳐 다음과 같은 계층 및 클래스 Interaction Diagram이

나왔다고 가정하도록 하겠다.

113


PresentationPresentation

aspx

WebForm(CodeBehind)

WebFormBase

DxFrameworkDxFramework

.NET Framework.NET Framework

FormBase

Page

Business FaBusiness Faççadeade

xxxFacade

MarshalByRef

Business RuleBusiness Rule

xxx_RTx

xxx_NTx

Data AccessData Access

xxxDacRuleBase

ServiceComponent

DacBase

xxxDbAgent

ADO.NETProv ider

Parent-Child Call Context

DataPack

DataPack

DataPack

DataPack

DataPack

SqlParameter[]

[그림 47] 계층 및 클래스 Interaction Diagram

화면을 시점으로 할 때, 하나의 화면 내에서 일어나는 애플리케이션의 흐름은 다음과 같다.

1. 사용자로부터 요청을 받는다. 입력 값이 있는 경우, UI 컨트롤을 통해 입력 데이터를 받는다.2. Business Façade 계층의 메서드를 호출하여, 입력 데이터를 넘긴다.3. Business Rule 계층의 메서드를 호출하여, 입력 데이터를 넘긴다.4. Business Rule 계층에서는 입력 데이터를 업무 규칙에 따라 처리 및 가공한 후, Data Access

계층의 메서드를 호출하여 처리된 데이터를 넘긴다.5. Data Access 계층에서는 데이터를 DB에 호출할 때 사용할 명령(쿼리 또는 저장 프로시저)의

매개변수로 만든 후, 명령을 실행한다.반환값이 있는 경우, 값을 Business Rule 계층으로 반환한다.

6. Business Rule 계층에서는 업무 규칙에 따라 가공한 후, 결과값을 Business Façade로 반환한다.7. Business Façade 계층에서는 결과값을 Presentation 계층으로 반환한다.8. Presentation 계층에서 결과값을 처리한다. 필요한 경우, 결과 데이터를 화면에 출력한다.

위 내용은 실제로 개발자가 코드를 작성해야 하는 흐름을 의미한다. 일반적인

114


애플리케이션이라면 그냥 구현해도 상관없지만, 여러 개의 계층으로 구성된 엔터프라이즈

애플리케이션에서는 몇 가지 추가사항들을 고려해야 한다.

반복되는 코드를 어떻게 줄일 것인가? 계층 간에 데이터를 어떻게 전달할 것인가? 사용자의 입력을 어떻게 받을 것인가? 사용자에 화면에 어떻게 출력할 것인가? 트랜잭션은 어떻게 제어할 것인가? 데이터베이스 커넥션은 어떻게 관리할 것인가? 예외 발생 시 어떻게 처리할 것인가?

이후부터는 애플리케이션 흐름과 위의 고려사항을 어떻게 처리해야 하는지를 프로그래밍

지침으로 알아보기로 한다.

3.3.2. 계층 간 데이터 전달

여러 개의 계층으로 나누어진 애플리케이션의 경우, 계층 간에 데이터를 어떻게 전달할 것인지가

핵심적인 사항 중 하나이다. 데이터들을 일일이 별도의 매개변수로 넘기게 된다면 계층이

많을수록 매우 반복적인 코드를 작성해야 하는 어려움이 있으며, 분산 애플리케이션의 경우

매개변수가 프로세스의 경계를 건너갈 수 있으므로 프로세스간의 마샬링 또한 고려해야 한다.다음은 계층 간에 데이터를 전달하는 여러가지 방법들을 기술하고 있다.

3.3.2.1. 별도의 메서드 매개변수로 전달

가장 전통적인 방법으로 값들을 일일이 별도의 메서드 매개변수로 전달하는 것이다.

// Presentationint empNo = EmpNo.Text;string empName = EmpName.Text;string address = Address.Text;…EmployeeInfoFacade employeeInfo = new EmployeeFacade();employeeInfo.AddNewEmployee(empNo, empName, address, …);

‘ PresentationDim empNo as Integer = EmpNo.TextDim empName as String = EmpName.Text

115


Dim address as String = Address.TextDim employeeInfo as new EmployeeInfoFacade()employeeInfo.AddNewEmployee(empNo, empName, address, ….)

// Business Façadepublic class EmployeeInfoFacade : MarshalByRefObject {public void AddNewEmployee(int empNo, string empName, string address, …) {EmployeeInfo_Tx employeeInfo = new EmployeeInfo_Tx();employeeInfo.AddNewEmployee(empNo, empName, address, …); }}

‘Business FaçadePublic Class EmployeeInfoFacade : Inherits MarchalByRefObject

Public Sub AddNewEmployee(ByVal empNo as Integer, ByVal empName as String, _ ByVal address as String)

Dim employeeInfo as new EmployeeInfo_nTx()employeeInfo.AddNewEmployee(empNo,empName, address…)

End SubEnd Class

// Business Rule[Transaction(TransactionOption.Required)]public class EmployeeInfo_Tx : RuleBase {public void AddNewEmployee(int empNo, string empName, string address, …) {Employee_Dac employeeDac = new Employee_Dac();employeeDac.Insert(empNo, empName, address, …); }}

‘Business Rule<Transaction(TransactionOption.Required)> _Public Class EmployeeInfo_Tx : Inherits RuleBase

Public Sub AddNewEmployee(ByVal empNo as Integer, ByVal empName as String, _

116


ByVal address as String)Dim employeeDac as new Employee_Dac()employeeDac.Insert(empNo, empName, address)

End SubEnd Class

// Data Access[Transaction(TransactionOption.Supported)]public class Employee_Dac : DacBase {public void Insert(int empNo, string empName, string address, …) {…// empNo를 DB 매개변수 처리

// empName을 DB 매개변수 처리

// address를 DB 매개변수 처리

}}

‘Data Access<Transaction(TransactionOption.Supported)> _Public Classs Employee_Dac : Inherits DacBase

Public Sub Insert(ByVal empNo as Integer, ByVal empName as String, _ ByVal address as String)

..‘ empNo DB 매개변수 처리

‘ empName DB 매개변수 처리

‘ address DB 매개변수 처리

End SubEnd Class

장점

메서드에 넘겨야 하는 매개변수가 명확하다.

단점

위 코드에서 볼 수 있듯이 empNo, empName, address라는 매개변수를 매번 계층을

거칠때마다 메서드의 매개변수로 넘겨야 하는 것이 번거롭다는 걸 알 수 있다. 만약 매개변수의 개수가 많아지면 많아질수록 더욱더 불편해지며, 코딩량이 많아진다. 매개변수 중 하나를 생략해야 할 경우, 일일이 오버로딩을 만들어야 한다.

117


3.3.2.2. Entity 클래스 / 구조체로 전달

넘겨야 할 데이터를 Entity 형태의 클래스 또는 구조체로 정의한 후, 클래스 또는 구조체 변수를

통째로 전달하는 방식이다.

// Entity 클래스 정의

public class EmployeeEntity {// 필드 정의

private int empNo = 0;private string empName = null;private string address = null;…// 속성 정의

public string EmpNo { get { return empNo; } set { empNo = value; }}…}

‘Entity 클래스 정의

Public Class EmployeeEntity‘필드정의

Private m_EmpNo as Integer = 0Private m_EmpName as String = NothingPrivate m_Address as String = Nothing

‘속성정의

Public Property EmpNo as StringGet

Return m_EmpNoEnd GetSet(Byval Value as String)

m_EmpNo = ValueEnd Set

End PropertryEnd Class

118


// PresentationEmployeeEntity employee = new EmployeeEntity(); // Entity 생성

employee.EmpNo = EmpNo.Text; // Entity에 값을 채움

employee.EmpName = EmpName.Text;employee.Address = Address.Text;…EmployeeInfoFacade employeeInfo = new EmployeeFacade();employeeInfo.AddNewEmployee(employee);

‘PresentationDim employee as new EmployeeEntityemployee.EmpNo = EmpNo.Textemployee.EmpName = EmpName.Textemployee.Address = Address.Text…Dim employeeInfo as new EmployeeFacade()employeeInfo.AddNewEmployee(employee)

// Business Façadepublic class EmployeeInfoFacade : MarshalByRefObject {public void AddNewEmployee(EmployeeEntity employee) {EmployeeInfo_Tx employeeInfo = new EmployeeInfo_Tx();employeeInfo.AddNewEmployee(employee); }}

‘Business FaçadePublic Class EmployeeInfoFacade : Inherits MarchalByRefObject

Publiic Sub AddNewEmployee(ByVal employee as EmployeeEntity)Dim employeeInfo as new EmployeeInfo_Tx()employeeInfo.AddNewEmployee(employee)

End SubEnd Class

// Business Rule

119


[Transaction(TransactionOption.Required)]public class EmployeeInfo_Tx : RuleBase {public void AddNewEmployee(EmployeeEntity employee) {Employee_Dac employeeDac = new Employee_Dac();employeeDac.Insert(employee); }}


Publiic Sub AddNewEmployee(ByVal employee as EmployeeEntity)Dim employeeDac as new Employee_Dac()employeeDac.Insert(employee)

End SubEnd Class

// Data Access[Transaction(TransactionOption.Supported)]public class Employee_Dac : DacBase {public void Insert(EmployeeEntity employee) {…// employee.EmpNo를 DB 매개변수 처리

// employee.EmpName을 DB 매개변수 처리

// employee.Address를 DB 매개변수 처리

}}

‘Data Access<Transaction(TransactionOption.Supported)> _Public Class Employee_Dac : Inherits DacBase

Publiic Sub Insert(ByVal employee as EmployeeEntity)‘employee.EmpNo 를 DB 매개변수 처리

‘employee.EmpName을 DB 매개변수 처리

‘employee.Address를 DB 매개변수 처리

End Sub

120


End Class

장점

계층 간 전달 시 하나의 매개변수로 전달할 수 있다. 정의한 Entity를 다른 곳에서 재활용할 수 있다.

단점

사용할 Entity를 사전에 정의해 두어야 한다. 이를 사전에 파악하고 만들어 두는 것은

쉽지 않은 작업이며, Entity가 정의되기 전까지 모든 계층의 메서드 매개변수 type을 확정할 수가

없다. Entity에 값을 get / set 할 때 멤버 단위로 일일이 수행해야 한다. 생략 가능한 값과 그렇지 않은 값을 구분하기가 모호하다. Entity 매개변수를 전달받은

쪽에서 값이 제대로 들어있는지를 일일이 확인해봐야 한다. Entity에 포함되지 않은 매개변수를 같이 넘겨야 하는 경우, 별도의 메서드 매개변수로

전달할 때와 동일한 단점이 발생한다.3.3.2.3. 데이터 컨테이너 사용 - DataSet

.NET에서는 기본적으로 계층 간 데이터 전달에 사용할 수 있도록 DataSet이라는 데이터

컨테이너를 제공한다. DataSet은 XML 구조를 기반으로 계층화된 데이터를 저장할 수 있게

해준다.

장점

데이터를 XML 기반으로 저장한다. 계층 간 전달(마샬링)을 지원한다. DataSet 안에 들어갈 요소를 동적으로 추가/수정/삭제할 수 있다. UI 컨트롤에 데이터바인딩을 지원한다. Presentation 계층으로 데이터를 반환할 때 최적이다.

단점

반드시 DataSet – DataTable – DataRow의 구조를 가져야 하므로 다루기 복잡하다. 사이즈가 크고 무겁다. 여러 개의 Row에는 적합하나, 1개의 Row나 1개의 값을 전달할 때는 적합하지 않다.

DataSet의 경우 여러 개의 레코드를 한번에 업데이트할 경우에는 적합하지만, 1개의 레코드나

값에는 적합하지 않으므로, Presentation에서 Business – Data Access로 전달할 때보다는

Data Access – Business에서 Presentation으로 전달할 때(조회한 결과집합 반환 시) 주로

사용한다.

121


3.3.2.4. 데이터 컨테이너 사용 - DataPack

DxFrameworkLite 내에는 위와 같은 문제점들을 해결하기 위해 계층 간 데이터 전달(특히

Presentation에서 Business – Data Access로 전달할 때)에 사용하기 위한 데이터 컨테이너

클래스인 DataPack을 제공한다.

// PresentationDataPack employeePack = new DataPack(); // DataPack 생성

employeePack.AddProperty("EmpNo", typeof(int)); // 동적으로 속성 추가

employeePack.AddProperty("EmpName", typeof(string));employeePack.AddProperty("Address", typeof(string));

employeePack["EmpNo"] = EmpNo.Text; // DataPack의 속성에 값을 채움

employeePack["EmpName"] = EmpName.Text;employeePack["Address"] = Address.Text;…EmployeeInfoFacade employeeInfo = new EmployeeFacade();employeeInfo.AddNewEmployee(employeePack);

‘PresentationDim employeePack as new DataPack() ‘DataPack 생성

employeePack.AddProperty(“EmpNo”, GetType(Integer)) ‘동적으로 속성 추가

employeePack.AddProperty(“EmpName”, GetType(String))employeePack.AddProperty(‘Address”, GetType(String))

// Business Façadepublic class EmployeeInfoFacade : MarshalByRefObject {public void AddNewEmployee(DataPack employeePack) {EmployeeInfo_Tx employeeInfo = new EmployeeInfo_Tx();employeeInfo.AddNewEmployee(employeePack); }}

‘Business FaçadePublic Class EmployeeInfoFacade : Inherits MarshalByRefObject

Public Sub AddNewEmployee(Byval employeePack as DataPack)Dim employeeInfo = new EmployeeInfo_Tx()

122


employeeInfo.AddNewEmployee(employeePack)End Sub

End Class

// Business Rule[Transaction(TransactionOption.Required)]public class EmployeeInfo_Tx : RuleBase {public void AddNewEmployee(DataPack employeePack) {Employee_Dac employeeDac = new Employee_Dac();employeeDac.Insert(employeePack); }}


Public Sub AdNewEmployee(ByVal employeePack as DataPack)Dim employeeDac as new Employee_Dac()employeeDac.Insert(employeePack)

End SubEnd Class

// Data Access[Transaction(TransactionOption.Supported)]public class Employee_Dac : DacBase {public void Insert(DataPack employeePack) {…// DataPack 속성과 값을 DB 매개변수의 배열로 변환

SqlParameter[] paramArray = employeePack.ToSqlParameter(); }}

‘Data Access<Transaction(TransactionOption.Supported)> _Public Class Employee_Dac : Inherits DacBase

Public Sub Insert(ByVal employeePack as DataPack)

123


…‘DataPack 속성과 값을 DB 매개변수의 배열로 변환

Dim paramArray as SqlParameter() = employeePack.ToSqlParameter()End Sub

End Class

124


장점

계층 간 데이터 전달 시 하나의 매개변수로 전달할 수 있다(마샬링 지원). 모든 Business – Data Access 클래스의 메서드 매개변수를 DataPack type으로

단일화할 수 있다. 동적으로 속성을 마음대로 추가/수정/삭제할 수 있다. 다른 매개변수를 같이 전달해야

하는 경우, 선택에 따라서 넘어온 DataPack에 속성을 추가해서 보낼 수도 있다. DataPack을 생성, DataPack에 속성을 추가/수정/삭제하는 것을 디자인 타임에서

수행할 수 있다. RequestInfo의 메서드를 사용하면, DataPack에 컨트롤의 값을 채우는 것을 단 한줄로

해결할 수 있다. 단, 이 때 컨트롤의 ID가 DataPack의 속성명과 일치해야 한다. DataPack에서 DB 매개변수의 배열로 한번에 변환할 수 있다(예 : ToSqlParameter 사용). 그외에 다른 타입으로의 변환을 지원한다.

단점

화면 마다 DataPack의 속성을 디자인해야 한다. 생략 가능한 값과 그렇지 않은 값을 구분하기가 모호하다.

3.3.2.5. 권장 사항

계층 간 데이터 전달 시에는 가능한 한 DataPack을 사용하는 것을 권장한다. DataPack 단일

매개변수로 전달하기 곤란하거나 의미가 모호해지는 경우에는 별도의 매개변수로 분리해서

전달하는 것이 좋다.

3.3.3. Presentation Layer 개발 지침

Presentation 계층은 크게 ASP.NET을 사용하여 웹 폼(Web Form)으로 개발하거나, Windows Form을 사용하여 윈도우 애플리케이션으로 개발하는 두 가지 종류가 있다. 각각 계층을 개발할

때 따라야 하는 지침에 대해서 알아보도록 한다.

3.3.3.1. ASP.NET Web Form3.3.3.1.1. 웹 폼 클래스 계층 구조

ASP.NET을 사용하여 웹 애플리케이션을 개발 시에, Code-Behind 구조를 최대한 활용하도록

권장한다. Code-Behind는 Inline 코딩에 비해 코드의 가독성과 유지보수성을 크게 높여주며, UI(HTML)와 UI 핸들링 코드를 구분할 수 있게 해준다.웹 폼 페이지는 기본적으로 System.Web.UI.Page 클래스로부터 상속을 받는다. 하지만 Page 클래스로부터 상속을 받는 대신, 공통적인 기능을 수행하는 새로운 부모 웹 폼 클래스를 정의하여

상속을 받도록 한다. 또한, 이러한 상속 구조는 다단계로 구현될 수도 있다. 다음은 구현가능한 웹

125


폼 클래스 계층 구조의 예를 든 것이다.

[그림 48] 웹 폼 클래스 계층 구조의 예

3.3.3.1.2. ASP.NET 서버 컨트롤의 활용

웹 폼 작성 시에는 ASP.NET 서버 컨트롤을 최대한 활용하도록 한다. 기존에 제공되는 서버

컨트롤이나 자신이 직접 서버 컨트롤을 작성하여, 코드 재사용성과 개발 생산성을 높이도록 한다. 페이지 내에 UI와 관련하여 계속적으로 반복되는 부분이 있다면 컨트롤화 하는 것을 권장한다. 또한 HTC와 CSS를 적극적으로 활용하도록 한다.

3.3.3.1.3. Fetch와 DataBind

웹 폼의 주요 역할 중 하나는 사용자로부터 입력을 받아 Business Logic으로 전달하는 것이다. 일반적으로 UI 컨트롤로부터 어떤 값을 입력받은 후, 이 값을 DataPack에 집어 넣은 후, Business Façade(또는 Business Rule)의 메서드를 호출하면서 전달하게 되는데, 이러한

과정을 Fetch라고 부른다. 전달되는 데이터는 Select 동작인 경우 검색조건, Insert/Update/Delete의 경우 처리할 값들인 경우가 많다.

126

System.Web.UI.Page

DxFrameworkLite.Web.UI.FormBase

WebRootBase

WebFormBase WebDialogBase

일반 웹 폼 클래스 팝업창 웹 폼 클래스

.NET 기본

웹 폼 템플릿 지원 기능

인증/권한, 상태정보 관리 등

일반 웹폼공통기능 팝업창 공통 기능


DataPackDataPack

DataSetDataSet

WebFormWebForm

Business Business FaFaççadeade

DataBindDataBind

FetchFetch

SelectSelect

Insert/Update/Insert/Update/DeleteDelete

[그림 49] Fetch 와 DataBind

Business Logic은 반환해야 할 데이터가 있는 경우, 대부분 DataSet으로 반환하게 된다(단일

값을 반환하는 경우는 제외). 웹 폼에서는 반환된 데이터를 페이지에 출력해야 하는데, 일반적으로 데이터바인딩을 지원하는 컨트롤에 바인딩을 하게 되는데, 이를 DataBind라고

부른다.

3.3.3.1.4. Load와 PreRender 이벤트

ASP.NET 웹 폼 작업 시에는 웹 폼의 이벤트 발생 순서에 대한 이해가 필수적이다. 전체 이벤트

발생 순서에 대해서는 MSDN을 참조하기로 하고 자주 사용되는 이벤트에 대해서만 알아본다.순서 용도

Load 컨트롤 이벤트 발생 전 페이지가 호출될 때마다 수행되어야 하는

동작 중 컨트롤의 이벤트 발생 전에

일어나야 되는 것

컨트롤의 이벤트 각 컨트롤의 이벤트

(Button.Click 등)컨트롤 이벤트 핸들러

PreRender 컨트롤 이벤트 발생 후 컨트롤 이벤트를 처리한 후에 페이지가

호출될 때마다 수행되어야 하는 동작

참고로 Load의 경우, ASP.NET 웹 폼 사용 시에 기본적으로 Page_Load라는 이벤트 핸들링

메서드가 만들어져 있으나, PreRender의 경우 직접 추가해야 한다(Page_PreRender라는

이름을 권장). 추가하는 방법은 속성창에서 웹 폼의 이벤트를 선택하고, PreRender 이벤트를

클릭하거나, 다음과 같은 코드를 추가한다.(VB.net의 경우, 코딩 창에서 왼편의 객체 목록에서

127


(Page Events) 항목을 선택하고 오른쪽 편의 이벤트 리스트에서 PreRender 이벤트를 선택한다)

//C#private void InitializeComponent(){…this.PreRender += new System.EventHandler(this.Page_PreRender);}

private void Page_PreRender(object sender, System.EventArgs e) {}

‘VB.netPrivate Sub Page_PreRender(ByVal sender As Object, _ ByVal e As System.EventArgs) Handles MyBase.PreRenderEnd Sub

3.3.3.1.5. 구현 순서

웹 폼을 구현하는 순서는 일반적으로 다음과 같다.1. 웹 폼 UI를 디자인한다. 전체적인 레이아웃을 잡고, 필요한 컨트롤을 배치한다.2. 디자이너로부터 HTML을 받은 경우는, 컨트롤 중에서 이벤트 핸들링이 필요한 것을 서버

컨트롤로 바꾼다.3. 컨트롤의 ID를 지정한다. RequestInfo 클래스를 사용하려면, 컨트롤의 ID를 DataPack

에 담을 속성명(또는 대상 DB 테이블의 필드명)과 일치시키는 것이 좋다.4. 반환받을 값이 있는 경우, DataSet을 추가한다. 가능하면 Typed DataSet을 만드는 것이

좋다.5. DataPack을 추가하고, DataPack에 속성을 만든다. DataPack 디자인은 AddProperty

메서드로 수동으로 코드로 지정하거나, 디자인 타임에서 수행할 수 있다. 디자인

타임에서는 기존에 추가된 Typed DataSet이 있으면 DataPack을 좀 더 쉽게 만들 수

있다.6. 웹 폼 또는 컨트롤의 이벤트 핸들러를 추가한다. (예 : Button의 Click 이벤트)7. 컨트롤의 입력값을 DataPack에 넣는다. 수동으로 넣거나, RequestInfo를 활용한다.

RequestInfo를 사용하려면 반드시 컨트롤의 ID와 DataPack 안의 속성 이름들이

일치해야 한다는 것에 주의한다.

//C#DataPack conditionPack = new DataPack();

128


…// 방법1 : 수동으로 FetchconditionPack["EmpNo"] = EmpNo.Text;conditionpack["EmpName"] = EmpName.Text;conditionpack["Address"] = Address.Text;…

// 방법2 : DxFrameworkLite.Data.RequestInfo 활용

RequestInfo.InputToDataPack(conditionPack)

‘VB.netDim conditionPack as new DataPack()…‘방법 1 : 수동으로 FetchconditionPack(“EmpNo”) = EmpNo.TextconditionPack(“EmpName”) = EmpName.TextconditionPack(“Address”) = Address.Text

‘방법 2 : DxFrameworkLite.Data.RequestInfo 활용

RequestInfo.InputToDataPack(conditionPack)

8. DataPack을 매개변수로 Business Logic의 메서드를 호출한다.9. 메서드가 Typed / Untyped DataSet을 반환하는 경우, 폼에 추가한 DataSet에서

받는다(또는 Merge 메서드로 병합).10. 출력할 컨트롤(예 : DataGrid)의 DataSource로 위 DataSet을 지정하고, DataBind()를

호출하여 데이터바인딩한다.3.3.3.2. Windows Form

3.3.3.2.1. Windows Form 클래스 계층 구조

웹 폼이 클래스 상속만 지원하는데 비해, Windows Form의 경우 UI까지 상속을 받을 수 있다. 상속된 폼을 만들려면 코드에서 상속받을 폼을 지정하거나, [프로젝트 메뉴]에서 [상속된 폼]을

선택한다. 폼 이름을 변경하고, 확인을 누르면 다음과 같은 [상속 선택] 상자가 나타난다.

129


[그림 50] Windows 폼 상속 선택

기본적으로는 현재 프로젝트에 있는 폼(이때 해당 프로젝트는 빌드되어 있어야 함)이 나타난다. [찾아보기] 버튼을 눌러서 다른 exe나 dll을 지정할 수도 있다. 상속할 구성요소를 선택하고, [확인]을 누르면 새로운 폼이 추가된다. 아래 그림은 상속된 폼이며, 상속 후에 다른 컨트롤을

추가했다.

[그림 51] 상속된 폼의 컨트롤

상속된 폼에 속하는 컨트롤에는 그림 표시( )가 붙는다. 이 컨트롤을 선택해보면 파란색-흰색

테두리가 나타나며 크기 조정 및 이동이 불가능하다는 것을 알 수 있다. 이러한 제한은 부모

클래스에 컨트롤의 Modifiers가 무엇(public/private/protected 등)으로 지정되어 있는가에

따라서 변경될 수 있다. 참고로 폼에 삽입한 컨트롤은 기본값이 private(VB.net의 경우 Friend)이므로 읽기 전용 컨트롤로 간주되어 크기 조정 및 이동, 속성 변경 등이 불가능하다.

130


부모 폼을 변경했을 경우에는 단순히 저장하는 것만으로는 자식 폼에 반영되지 않으며, 반드시

다시 빌드를 수행해야 한다.

3.3.3.2.2. Windows Form 컨트롤의 활용

Windows Form은 ASP.NET보다 더욱 다양하고 강력한 컨트롤을 지원한다. 개별 컨트롤의

사용법에 대해서는 MSDN이나 다른 문서를 참조하기 바란다. Windows Form도 역시 사용자 정의 컨트롤을 만들 수 있다. Windows Form의 내부를 컨트롤로

만들면, 차후에 웹 페이지에 임베딩된 형태로 개발할 때 유리하다.

3.3.3.2.3. Fetch와 DataBind

웹 폼의 경우와 동일하다. 구현 시에는 다소 차이가 나므로 구현순서를 참고하도록 한다.

3.3.3.2.4. Windows Form의 이벤트

Windows Form은 웹 폼에 비해 매우 다양하고 많은 이벤트를 지원한다. 기본적으로 Windows 애플리케이션이 가지고 있는 이벤트를 모두 지원한다. 대표적으로 사용되는 이벤트들은 다음과

같다.순서 용도

Load 폼이 로드될 때마다 폼이 로딩될 때 초기화 작업

Closing 폼이 닫히기 전에 발생 폼을 닫거나 작업 취소 여부 확인

Closed 폼이 닫힌 후에 발생 폼이 닫힐 때 정리 작업 수행

3.3.3.2.5. 구현 순서

기본적으로 Windows Form의 구현 순서는 웹 폼의 경우와 동일하며 몇가지 차이점만을 들면

다음과 같다. Fetch 시에 RequestInfo를 사용할 수 없이 수동으로 작업해야 한다. DataBind 시에 컨트롤의 DataBind() 메서드를 호출해줄 필요가 없다. Windows Form의 경우, 컨트롤에 Data Source를 지정하고 Data Source에 값을 채우거나 변경하면

자동적으로 즉각 바인딩 되어 반영된다. Windows 애플리케이션 및 컨트롤의 특성에 따라서 작업을 수행한다.

3.3.4. Business Façade Layer 개발 지침

Business Façade 계층은 Business Rule 계층에 대해 Factory 패턴을 제공함으로써 트랜잭션

유무에 관계없이 사용할 수 있게 해준다. 또한, 외부에 노출시키는 방법으로 .NET Remoting을

131


사용하거나 웹 서비스를 선택할 수 있다.

3.3.4.1. .NET Remoting

.NET Remoting은 기존의 DCOM을 대치하여 애플리케이션 도메인 이상의 경계를 넘어갈 때

원격 메서드를 호출해줄 수 있게 해주는 기술이다. Remoting에 대한 자세한 설명은 MSDN을

참조하도록 한다. 다음은 .NET Remoting 사용 시 Business Façade의 구현 예제이다.

//C#[Serializable]class BusinessFacade : MarshalByRefObject { public DataSet Getxxxx(DataPack dataPack) { using ( BusinessRule_NTx bizNTx = new BusinessRule_NTx() ) { return bizNTx.Getxxxx(dataPack); } }

public void AddNewxxxx(DataPack dataPack) { using ( BusinessRule_Tx bizTx = new BusinessRule_Tx() ) { bizTx.AddNewxxxx(dataPack); } } ……}

‘VB.NET<Serializable> _Class BusinessFacade : Inherits MashalByRefObject

Public Function Getxxxx(ByVal dataPack as DataPack) as DataSetDim bizNTx as new BusinessRule_NTx()Dim retDs as DataSet = bizNTx.Getxxxx(dataPack)bizNTx.Dispose()Return retDs

132


End Function

Public Sub AddNewxxx(ByVa dataPack as DataPack)Dim bizTx as new BusinessRule_Tx()bizTx.AddNewxxx(dataPack)bizTx.Dispose()

End SubEnd Class

.NET Remoting 구현을 위해 MarshalByRefObject로부터 상속을 받는다. Business Rule 계층의 클래스(_NTx, _Tx)를 생성, 호출

3.3.4.2. 웹 서비스(Web Services)

SOAP 호출을 통해 원격 메서드를 호출할 수 있게 해주는 기술이며, .NET에서는 일반적으로

ASP.NET 웹 서비스를 통해 구현한다. ASP.NET 웹 서비스에 대한 자세한 설명은 MSDN을

참조하도록 한다. 다음은 웹 서비스 사용 시 Business Façade의 구현 예제이다.

//C#class BusinessService : System.Web.Services.WebService { [WebMethod] public DataSet Getxxxx(DataPack dataPack) { using ( BusinessRule_NTx bizNTx = new BusinessRule_NTx() ) { return bizNTx.Getxxxx(pack); } }

[WebMethod] public void AddNewxxxx(DataPack dataPack) { using ( BusinessRule_Tx bizTx = new BusinessRule_Tx() ) { bizTx.Insertxxxx(dataPack); } }

133


……}

‘VB.NETClass BusinessService : Inherits System.Web.Services.WebService

<WebMethod()> _Public Function Getxxxx(ByVal dataPack as DataPack) as DataSet

Dim bizNTx as new BusinessRule_NTx()Dim retDs as DataSet = bizNTx.Getxxxx(dataPack)bizNTx.Dispose()Return retDs

End Function

<WebMethod()> _Publilc Sub AddNewxxxx(ByVal datapack as DataPack)

Dim bizTx as new BusinessRule_Tx()bizTx.Insertxxxx(dataPack)bizTx.Dispose()

End SubEnd Class

ASP.NET 웹 서비스 프로젝트를 만들고, 웹 서비스를 추가한다. 그러면, *.asmx가

만들어지고 Code behind로 *.asmx.cs(*.asmx.vb)가 만들어진다. 만들어진 웹 서비스는 System.Web.Services.WebService로부터 상속받는다. 웹 서비스에서 노출할 메서드를 추가하고, 메서드에 WebMethod 특성을 적용한다.

3.3.5. Business Rule Layer 개발 지침

Business Rule 계층에서는 업무 로직을 기술하고, 트랜잭션의 제어 등 주요한 역할을 수행한다. 일반 클래스 형태로 Business Rule을 구현할 수도 있지만, 여기서는 .NET Enterprise Service(COM+)를 활용하는 Serviced Component로 구현하는 것을 설명하도록 한다.

3.3.5.1. RuleBase 클래스

.NET에서 Serviced Component(COM+ 서비스에 등록되는 컴포넌트)를 만들기 위해서는

클래스가 System.EnterpriseServices.ServicedComponent로부터 상속받도록 만들면 된다.일반적으로 Business Rule 계층 컴포넌트들의 공통적인 기능을 처리하기 위해 RuleBase라는

134


명칭의 기본 클래스를 만든다.

//C#using System.EnterpriseServices;abstract public class RuleBase : ServicedComponent{ …}

‘VB.netImports System.EnterpriseServicesPublic MustInherit Class RuleBase : Inherits ServicedComponent….End class

3.3.5.2. 트랜잭션이 필요하지 않은 클래스(_NTx) UseCase명 + _NTx로 클래스 이름을 짓는다. RuleBase로부터 상속을 받는다. Transaction 특성에 NotSupported로 지정한다. JustInTimeActivation 특성을 지정한다. 트랜잭션이 필요하지 않은 동작(주로 Select)을 수행하는 메서드를 선언하고, AutoComplete 특성을 지정한다.

다음은 트랜잭션이 필요하지 않은 Business Rule 클래스의 예이다. Transaction 특성 및

AutoComplete에 관한 부분은 3.3.8 트랜잭션 처리 를 참조하도록 한다.

//C#[Transaction(TransactionOption.NotSupported)][JustInTimeActivation(true)]public class BusinessRule_NTx : RuleBase{ [AutoComplete] public DataSet Getxxxx(DataPack dataPack) { // Business Logic을 처리..

// DAC 호출

135


using ( Table1_Dac dacObj = new Table1_Dac() ) { return dacObj.Select(dataPack); } }}

‘VB.net<Transaction(TransactionOption.NotSupported), JustIntimeActivation(True)> _Public Class BusinessRule_NTx : Inhertis RuleBase

<AutoComplete> _Public Function Getxxx(ByVal dataPack as DataPack) as DataSet

‘Business Logic 처리

‘DAC 호출

Dim dacObj as new Table1_Dac()Dim retDs as DataSet = dacObj.Select(dataPack)dacObj.Dispose()Return dacObj

End FunctionEnd Class

3.3.5.3. 트랜잭션이 필요한 클래스(_Tx) UseCase명 + _Tx로 클래스 이름을 짓는다. RuleBase로부터 상속을 받는다. Transaction 특성에 Required로 지정한다. JustInTimeActivation 특성을 지정한다. 트랜잭션이 필요한 동작(주로 Insert, Update, Delete)을 수행하는 메서드를 선언하고, AutoComplete 특성을 지정한다.다음은 트랜잭션이 필요한 Business Rule 클래스의 예이다.

//c#[Transaction(TransactionOption.Required)][JustInTimeActivation(true)]public class BusinessRule_Tx : RuleBase{ [AutoComplete] public void AddNewxxxx(DataPack dataPack)

136


{ // 비즈니스 로직을 처리

// Table1에 Insert using ( Table1_Dac dacObj1 = new Table1_Dac() ) { dacObj1.Insert(dataPack); }// Table2에 Insert using ( Table2_Dac dacObj2 = new Table2_Dac() ) { dacObj2.Insert(dataPack); } }}

‘VB.net<Transaction(TransactionOption.Required), JustInTimeActivation(True)> _ Public Class BusinessRule_Tx : Inherits RuleBase

<AutoComplete> _Public Sub AddNewxxxx(ByVal dataPack as DataPack)

‘비즈니스 로직을 처리

‘Table1에 InsertDim dacObj1 as new Table1_Dac()dacObj1.Insert(dataPack)dacObj1.Dispose

‘Table2에 InsertDim dacObj2 as new Table2_Dac()dacObj2.Insert(dataPack)dacObj2.Dispose

End SubEnd Class

3.3.6. Data Access Layer 개발 지침

Data Access 계층에서는 실제로 쿼리나 저장 프로시저(Stored Procedure) 명령을 실행하는

137


곳이다. 원칙적으로는 ADO.NET을 직접 호출해야 하지만, ADO.NET을 보다 사용하기 편하게

만든 DxFrameworkLite.Data.SqlDbAgent (Oracle인 경우, OracleDbAgent)를 사용하도록

한다.

3.3.6.1. DacBase 클래스

SqlDbAgent의 경우 자주 사용되므로, Data Access 계층 클래스의 메서드를 호출할 때

SqlDbAgent를 생성 및 정리해주는 기능을 기본 클래스에서 제공하고, 이를 상속받도록

구현하는 것이 좋다. DacBase 역시 Serviced Component로 작성한다.

//C#using System.EnterpriseServices;using DxFrameworkLite.Data;

public class DacBase : ServicedComponent { protected SqlDbAgent _agent;…protected override void Activate() { _agent = new SqlDbAgent();}protected override void Deactivate() { _agent.Dispose();}}

‘VB.netImports System.EnterpriseServicesImports DxFrameworkLite.Data

Publilc Class DacBase : Inherits ServicedComponentProtected SqlDBAgent _agent

Protected Overrides Sub Activate()_agent = new SqlDBAgent()

End Sub

138


Protected Overrides Sub Deactivate()_agent.Dispose()

End SubEnd Class

3.3.6.2. DAC 클래스 작성 Table 명 + _Dac로 클래스 이름을 짓는다. DacBase로부터 상속을 받는다. Transaction 특성에 Supported로 지정한다. JustInTimeActivation 특성을 지정한다. Data Source에 명령을 실행하는 메서드를 작성하고, AutoComplete 특성을 지정한다.다음은 Data Access 클래스를 정의한 예이다.

[Transaction(TransactionOption.Supported)][JustInTimeActivation(true)]class Table1Dac : DacBase{[AutoComplete]public void Select(DataPack dataPack) { …}

[AutoComplete]public void Insert(DataPack dataPack) { …}}

<Transaction(TransactionOption.Supported), JustInTimeActivation(True)> _Public Class Table1_Dac : Inherits DacBase

<AutoComplete> _Public Sub Select(ByVlal dataPack as DataPack)…..End Sub

<AutoComplete> _Publilc Sub Insert(ByVal dataPack as DataPack)

139


…End Sub

End Class

3.3.6.3. DAC 클래스 메서드 작성 실행할 명령(쿼리 또는 SP명)을 정의한다. 쿼리의 경우, 상황에 따라

DxFrameworkLite.Data.QueryBuilder를 이용하여 만들 수도 있다. 전달받은 매개변수를 바탕으로 명령에 사용할 SqlParameter (Oracle의 경우

OracleParameter)의 배열을 만든다. 일반적으로 DataPack의 ToSqlParameter 메서드를

사용하여 생성한다. ToSqlParameter는 전달된 DataPack 내부의 속성에 @(Oracle의 경우 : )를 붙여서 생성하므로, 쿼리나 SP내에 ‘@속성명’ 형태의 매개변수가 정의되어 있어야 한다.

SqlDbAgent의 Fill/Update/ExecuteNonQuery/ExecuteScalar 메서드 중 하나를

호출하여 명령을 실행한다. Fill인 경우, 채워진 DataSet을 반환한다. ExecuteScalar인 경우는 단일값을 반환한다.3.3.6.3.1. 쿼리를 사용하는 경우

문자열 더하기 쿼리 대신에 매개변수화된 쿼리(Parameterized Query)를 사용하도록

한다.

//C#string strQuery = "SELECT * FROM table WHERE UserName = '" + userName + "'"; // 쓰지 말것

string strQuery = "SELECT * FROM table WHERE UserName = @UserName"; // 권장안

‘VB.netDim strQuery as String = "SELECT * FROM table WHERE UserName = ‘ “ + userName + “ ‘ “ ‘쓰지 말것

Dim strQuery as String = "SELECT * FROM table WHERE UserName = @UserName" ‘권장안

상황에 따라 가능한 경우에는 QueryBuilder를 사용한다.QueryBuilder의 사용법은 QueryBuilder 클래스 설명을 참조한다.

//C#strQuery = QueryBuilder.BuildSelectQuery("SELECT * FROM table ", dataPack);

‘VB.netDim strQuery as String = QueryBuilder.BuildSelectQuery("SELECT * FROM table ", dataPack)

140


다음은 쿼리를 사용하는 경우, 메서드를 작성한 예이다.

//C#[AutoComplete]public DataSet Select(DataPack dataPack) { string strQuery = "SELECT * FROM table1 WHERE Field1 = @Field1 AND Field2 = @Field2 "; SqlParameter[] paramArray = dataPack.ToSqlParameter();

DataSet ds = new DataSet(); _agent.Fill(strQuery, "table1", ds, paramArray); // table1은 테이블 이름으로 대치

return ds;}

[AutoComplete]public void Insert(DataPack dataPack) { string strQuery = "INSERT INTO table1 (Field1, Field2, …) VALUES (@Field1, @Field2, …) "; SqlParameter[] paramArray = dataPack.ToSqlParameter();

_agent.ExecuteNonQuery(strQuery, paramArray);}

‘VB.net<AutoComplete> _Public Function Select(ByVal dataPack as DataPack) as DataSet

Dim strQuery as String = _ "SELECT * FROM table1 WHERE Field1 = @Field1 AND Field2 = @Field2”

Dim paramArray as SqlParameter() = dataPack.ToSqlParameter()Dim ds as new DataSet_agent.Fill(strQuery,”table1”,ds,paramArray) ‘table1은 테이블 이름으로 대치

Return dsEnd Function

141


<AutoComplete> _Public Sub Insert(ByVal dataPack as DataPack)

Dim strQuery as String = _"INSERT INTO table1 (Field1, Field2, …) VALUES (@Field1, @Field2, …)"Dim paramArray as SqlParameter() = dataPack.ToSqlParameter()_agent.ExecuteNonQuery(strQuery,paramArray)

End Sub

3.3.6.3.2. 저장 프로시저를 사용하는 경우

저장 프로시저를 쓸 때는 이름을 지정하고, CommandType.StoredProcedure로 형식을

지정해주는 것만 차이가 있다. 만약 저장 프로시저가 Output 매개변수를 반환하는 경우, SqlParameter에 Output 매개변수를 추가해야 한다.다음 예제에서는 저장 프로시저를 호출하여 결과값뿐만 아니라 @retVal이라는 Output 매개변수를 반환하고 있다.

//C#[AutoComplete]public DataSet Select(DataPack dataPack, out int totalCount) { // 호출할 sp명

string strQuery = "sp_Name";

DataSet ds = new DataSet();

SqlParameter[] paramArray = dataPack.ToSqlParameters();

// output 파라미터 추가. Add 메서드는 Direction 미지정시 output으로 간주함

DbParamHelper.Add(ref paramArray, "@retVal", SqlDbType.Int);

// CommandType을 StoredProcedure로 지정

_agent.Fill(strQuery, "table1", ds, paramArray, CommandType.StoredProcedure); // output 파라미터 값 읽어오기

totalCount = (int) DbParamHelper.GetValue(paramArray, "@retVal");

142


return ds;}

‘VB.net<AutoComplete> _Public Function Select(ByVal dataPack as DataPack, ByRef totalCount as Integer)

Dim strQuery as String = “sp_Name”Dim ds as new DataSet = new DataSetDim paramArray as SqlParameter() = dataPack.ToSqlParameters()

‘output 파라미터 추가. Add 메서드는 Direction 미지정시 output으로 간주함

DbParamHelper.add(paramArray,”@retVal”, SqlDbType.Int)

‘CommandType을 StoredProcedure로 지정

_agent.Fill(strQuery, “table1”,ds,paramArray,CommandType.StoredProcedure)

‘output 파라미터 값 읽어오기

totalCount = CInt(DbParamHelper.GetValue(paramArray,”@retVal”))Return ds

End Function

3.3.7. Database Connection 관리

3.3.7.1. 개요

분산 애플리케이션 환경에서는 데이터베이스 Connection 자원을 최대한 짧게 사용하고, 사용이

끝나면 바로 해제하는 것이 바람직하다. 이를 위해 DxFrameworkLite 내에서는 Connection과

관련한 코드를 프로그래머가 작성할 필요 없이 자동으로 관리한다.

3.3.7.2. 연결 문자열(Connection String)

ADO.NET에서는 데이터베이스에 연결하기 위해 다음과 같은 연결 문자열을 사용한다(Data Source의 종류에 따라 항목은 다소 차이가 있다).

"Data Source=dbserver; Database=database; User ID=userID; Password=password;"이러한 연결 문자열을 코드 내에 작성하게 되면, 관리 및 유지보수 시 어려움을 겪게 되므로, 구성

정보 파일(예: web.config) 내에서 통합하여 관리하고, 절대 개발자가 임의로 코드 내에

작성하지 않도록 한다. DxFrameworkLite.Data.SqlDbAgent는 구성 정보 파일 내의 연결

문자열을 읽어서 자동적으로 연결을 맺고 끊게 된다.

143


구성 정보 파일에 설정하는 부분에 대해서는 3.3.11 구성 정보 파일 처리 를 참조하도록 한다.

3.3.7.3. 연결 풀링(Connection Pooling)

ADO.NET Data Provider에서는 자동적으로 연결 풀링 기능을 제공한다. 연결 풀링은 연결

문자열마다 고유하게 만들어지며, 기본적으로 풀링이 활성화되어 있으며 최대 풀 개수는 100개로 설정되어 있다. 풀링 활성화 여부나 최대 풀 개수는 연결 문자열에서 변경할 수 있다.

Pooling=true/false; Max Pool Size=150;

3.3.7.4. 자동 Connection 관리

DxFrameworkLite.Data.SqlDbAgent의 Fill/Update/ExecuteNonQuery/ExecuteScalar 메서드 중 하나를 호출하면, 실제로는 다음과 같이 호출이 일어난다.

agent.Activate(); // Connecion을 Openagent.ExecuteNonQuery(); // 명령 수행

agent.Deactivate(); // Connection을 Close위와 같이 자동적으로 Activate, Deactivate가 호출되어 Connection을 열고 닫게 된다. 그러므로 개발자는 Connection을 열고 닫는 코드를 직접 작성할 필요가 없다.주의할 점은 ServicedComponent로 작성되는 Business Rule 및 Data Access 클래스의

메서드들에 JustInTimeActivation 및 AutoComplete 특성을 붙이는 것을 잊지 말아야 한다. 이

두가지 특성이 적용되어 있어야 메서드 호출 후 Deactivate가 호출되는 것이 보장된다. 이

세팅이 적용되지 않았을 경우, 일정 시간이 경과할 때까지 Connection이 제대로 닫히지 않을 수

있다.

3.3.8. 트랜잭션 처리

이 장에서는 분산 애플리케이션 개발 시 트랜잭션을 적절하게 관리하기 위한 방법에 대해서

설명한다. 트랜잭션에 대한 적절한 선택과 관리는 애플리케이션의 성능 향상은 물론, 확장성에도

영향을 미칠 수 있으므로 이에 대한 충분한 이해와 적절한 선택이 필요하다.

3.3.8.1. 개요

트랜잭션이란 일련의 여러 수행들을 하나의 작업단위로 처리하는 것을 말한다. 관련된 작업들을

하나의 단위로 트랜잭션 내에서 묶어냄으로써, 어떠한 오류에 대해서도 시스템의 일관성과

안정성을 보장 해 낼 수 있다. 트랜잭션 내의 모든 작업들이 성공적으로 완수 되어야 만, 해당하는

트랜잭션이 성공적으로 완료 될 수 있다.트랜잭션은 프로세스들과 머신들 사이를 하나로 엮어 낼 수 있는 시작과 끝의 경계를 가진다. 트랜잭션 경계내의 모든 리소스들은 동일한 트랜잭션 내에 참여한다. 이러한 트랜잭션 경계내의

144


리소스들의 일관성을 유지하기 위해서 트랜잭션은 ACID(Atomicity, Consistency, Isolation, Durability) 특징을 유지해야 한다.(ACID 참조 : http://msdn.microsoft.com/library/en-us/cpguide/html/cpconacidproperties.asp)트랜잭션은 로컬 트랜잭션과 분산 트랜잭션으로 나뉜다.로컬 트랜잭션이란 내부 트랜잭션 매니저에 의해서 Commit 혹은 Rollback 이 수행되는 것을

말하며, 분산 트랜잭션이란, 이종(heterogeneous) 트랜잭션이라고도 하며, 머신을 가리지 않고

특정 서버에서 데이터를 검색하고, 또 다른 데이터 베이스에 기록하는 등의 광범위한 리소스

관리를 수행 한다. 이러한 분산 트랜잭션에 대한 프로그래밍은 다양한 리소스들을 Commit 하거나 Rollback 혹은 복구하는 기능을 담당하는 트랜잭션 관리자에 의해서 이루어 진다. Microsoft Distributed Transaction Coordinator(DTC) 는 이러한 기능을 가지는 트랜잭션

관리자의 하나로써, 리소스 관리자(Resource Manager) 인터페이스를 구현해 놓은

애플리케이션들인 Microsoft SQL Server, MSMQ, Oracle, Sybase 등과 같은 것들 사이의

트랜잭션 관리에 사용된다.

3.3.8.2. 데이터베이스 트랜잭션

BEGIN TRANSACTION / COMMIT, ROLLBACK TRANSACTION 구문을 구현한 저장프로시저를

호출하는 방식을 말한다. 이러한 방식은 트랜잭션 관리는 데이터베이스 자체에 의존함으로써

성능 측면에서는 최상의 성능을 나타낸다. 이 이러한 이유중의 하나는 클라이언트와 서버 사이에

단일 라운드 트립(Round-trip)만으로 트랜잭션 처리를 가능케 할 수 있기 때문이다. 또한

데이터베이스 트랜잭션은 중첩 트랜잭션을 지원한다.통상적으로 데이터베이스 트랜잭션은 다음과 같은 저장 프로시저의 유형으로 구현할 수 있다.

CREATE PROCEDURE Proc1…AS -- 트랜잭션 시작

BEGIN TRANSACTION -- 트랜잭션 작업 수행

… -- 오류 체크

If @@Error <> 0 -- 트랜잭션 Rollback ROLLBACK TRANSACTION … -- 트랜잭션 Commit

145

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconacidproperties.asp


COMMIT TRANSACTION이 방식은 가장 빠른 성능을 제공하는 반면, 모든 코드를 Transact-SQL 내에서 구현해야 한다는

단점을 가진다.

3.3.8.3. ADO.NET 수동 트랜잭션

수동 트랜잭션은 명시적으로 begin / end 트랜잭션을 선언함으로써 트랜잭션 경계를 제어하는

방식을 말한다. 이러한 수동 트랜잭션은 중첩 트랜잭션을 지원하며, 활성 트랜잭션 내부에서 또

다른 새로운 트랜잭션을 시작할 수 있다.이러한 작업 방식은 여러분이 직접 데이터 리소스들을 트랜잭션 경계 내에 추가 시켜야 하고

이러한 리소스들을 관리해 주어야 한다. 또한 분산 트랜잭션을 지원하는 기능이 존재하지 않기

때문에, 분산 트랜잭션을 구현하기 위해서는 이에 참여하는 모든 커넥션들과 지원들에 대하여

직접 관리를 해 주어야 한다는 번거로움을 가진다.ADO.NET Managed Provider 는 데이터 베이스에 연결하는 Connection 객체와 관련한 객체에

트랜잭션을 begin, commit, rollback 하는 메소드를 제공한다. 이러한 메소드들을 이용하여

트랜잭션을 관리하는 방식을 ADO.NET 수동 트랜잭션이라고 한다.단일 트랜잭션 내에서 작업을 수행하기 위해서는 SQLTransaction 객체를 생성해야 한다. SQLConnection 객체를 사용하여 트랜잭션을 시작하고, 트랜잭션 내부에서 작업을 수행한 뒤에

트랜잭션에 대한 commit 혹은 rollback 을 호출한다.(주의) Command 객체의 Transaction 속성을 반드시 트랜잭션이 시작된 커넥션의 Transaction 객체로 지정해 주어야 한다.통상적으로 ADO.NET 수동 트랜잭션은 다음과 같은 코드 유형을 통하여 수행된다.

//C#SQLConnection Conn = New SQLConnection("ConnString");SQLCommand Cmd = New SQLCommand;// 트랜잭션을 시작한다

SQLTransaction Txn = Conn.BeginTransaction();

try {// 커넥션을 연다

Conn.Open();// 실행될 command 객체의 트랜잭션 속성에 트랜잭션 객체를 지정한다

Cmd.Transaction = Txn;// 트랜잭션 커밋

Txn.Commit();}

146


catch {// 예외 처리

// 트랜잭션 롤백

Txn.Rollback();}finally {Conn.Close();}

‘VB.netDim Conn As New SqlConnection("ConnString")Dim Cmd As New SqlCommand

'트랜젝션을 시작한다

Dim Txn As SqlTransaction = Conn.BeginTransaction

Try'커넥션을 연다

Conn.Open()'실행될 command 객체의 트랜젝션 속성에 트랜젝션 객체를 지정한다

Cmd.Transaction = Txn

'트랜젝션 커밋

Txn.Commit()Catch ex As Exception

'예외처리

'트랜젝션 롤백

Txn.Rollback()Finally

Conn.Close()End Try일반적으로 Connection 객체를 통한 Transaction 처리는 Try / Catch / finally 블록을 통하여

구현된다.저장 프로시저 내부에서 명시적으로 트랜잭션을 구현하는 것과 비교해 보자면, ADO.NET 의 수동

트랜잭션이 성능 면에서는 덜 효과적이다. ADO.NET 수동 트랜잭션이 저장 프로시저 내부에서

명시적으로 트랜잭션을 구현할 때 보다 명령을 수행하는 과정에서 더 많은 라운드 트립이

147


발생하며, 그 과정에 DBMS 와 ADO.NET 간에는 Lock 이 유지되어 있는 상황이기 때문이다.각각의 방식에 대한 비교는 이후 트랜잭션 관리방법 비교에 대해서 자세히 알아본다.

3.3.8.4. COM+ 수동 트랜잭션

자동 트랜잭션을 지원하기 위해서 .NET Framework 에서는 MTS / COM+ 서비스를 사용한다. COM+는 DTC(Distributed Transaction Coordinator)를 사용하여 분산 환경 하에서

트랜잭션을 수행한다. 명시적인 트랜잭션을 선언하는 프로그래밍 모델을 기반으로 COM+는

간단히 로직들로 이기종 리소스들과의 트랜잭션을 수행할 수 있게 한다.주의할 점은 DTC 과 COM InterOp을 사용하기 때문에 약간의 성능 저하를 가져온다는 것을 알아

두자..NET Class가 자동 트랜잭션에 참여하려면

System.EnterpriseServices.ServicedComponent 클래스를 상속 받아야 한다. COM+ 는

DTC와 연동하여 분산 트랜잭션을 생성하고, 모든 자원들을 해당하는 트랜잭션 내부에 enlist 시킨다.COM+ 수동 트랜잭션은 구현하기 위해서는 다음과 같은 코드 유형을 통하여 구현된다.

//C#[Transaction(TransactionOption.Required)]public class Class1 : ServicedComponent { public void TxMethod(...) { try { // 작업을 수행

ContextUtil.SetComplete(); } catch { ContextUtil.SetAbort(); } }}

‘’VB.net<Transaction(TransactionOption.Required)> _Public Class Class1 : Inherits ServicedComponent

Public Sub TxMethod()Try

148


'작업을 수행

ContextUtil.SetComplete()Catch ex As Exception

ContextUtil.SetAbort()End Try

End SubEnd Class얼핏 보기에는 SetComplete()이 Commit, SetAbort가 Rollback과 동일해 보이나, 실제로 이

의미는 다소 다르다. 분산 트랜잭션은 투표 모델(Voting)로 구현되며, 트랜잭션에 참여하는 모든

메서드가 Voting을 하고 난 후에 트랜잭션의 커밋과 롤백 여부가 결정된다. 모든 메서드가

SetComplete을 했을 경우에는 트랜잭션이 커밋되며, 메서드 중 하나라도 SetAbort를

호출하거나 Voting을 하지 않은 채 타임아웃이 걸리면 트랜잭션이 롤백된다.ServicedComponent에는 다음 중 하나로 TransactionOption을 지정할 수 있다.

Disabled – 이 객체는 COM+ 트랜잭션 내부에서 생성되지 않음을 지정한다. 이 객체는

트랜잭션 지원을 위해 직접 DTC를 사용할 수 있다. NotSupported – 이 객체는 트랜잭션 내부에서 생성되지 않음을 지정한다. Supported – 이 객체는 트랜잭션 생성자의 컨텍스트 내부에서 실행됨을 지정한다. 만일

이 객체가 루트 객체이거나, 생성자가 트랜잭션 내부에서 실행되지 않는다면 이 객체는 트랜잭션

없이 생성된다. Required – 이 객체는 트랜잭션 생성자의 컨텍스트 내부에서 실행됨을 지정한다. 만일 이

객체가 루트 객체이거나, 생성자가 트랜잭션 내부에서 실행되지 않는다면, 이 객체는 새로운

트랜잭션을 가지고 생성된다. RequiresNew – 이 객체는 트랜잭션이 필요로 하며, 이 객체는 새로운 트랜잭션을 가지고

생성된다

위 옵션에서 추측해서 볼 수 있듯이 트랜잭션은 Required 또는 RequiresNew로 지정된

클래스의 메서드를 호출할 때부터 시작되어 그 메서드의 Scope이 끝날 때 종료된다. 그리고, 메서드 내에서 Supported 또는 Required로 지정된 클래스의 메서드를 호출하는 경우에만, 트랜잭션에 포함되게 된다. 이 때 호출되는 메서드들은 모두 SetComplete이나 SetAbort를

호출하여 Voting을 해야 한다는 것에 유의한다.

3.3.8.5. COM+ 자동 트랜잭션

이전의 COM+ 수동 트랜잭션 코드를 보면 SetComplete이나 SetAbort를 호출하는데는

일반적인 패턴이 존재한다. try 블록 내에서 예외가 발생하지 않은 경우에는 SetComplete을, 예외가 발생한 경우에는 catch 블록 내에서 SetAbort를 호출하고 있음을 알 수 있다.자동 트랜잭션은 이러한 패턴을 바탕으로 메서드 내에서 예외가 발생하지 않으면 SetComplete

149


을, 예외가 발생하면 SetAbort를 자동으로 호출해준다. 자동 트랜잭션을 사용하기 위해서는

메서드에 AutoComplete 특성을 부여해주기만 하면 된다.자동 트랜잭션을 사용하면, try~catch 처리나 SetComplete/SetAbort 호출이 필요없으므로, 코드가 다음과 같이 매우 간결해진다.

//C#[Transaction(TransactionOption.Required)]public class Class1 : ServicedComponent { [AutoComplete] public void TxMethod(...) {// 작업을 수행

}}

‘VB.net<Transaction(TransactionOption.Required)> _Public Class Class1 : Inherits ServicedComponent

<AutoComplete()> _Public Sub TxMethod()

'작업을 수행

End SubEnd Class

3.3.8.6. 트랜잭션 방법 비교

앞서 살펴본 크게 3가지의 트랜잭션 관리 방법들을 중심으로 각각의 옵션들에 대한 장단점들을

비교해보자. 각각의 트랜잭션 구현 기술들에는 각각 성능과 코드 관리 측면의 Trade-Off 를

가진다. 데이터베이스 트랜잭션

데이터베이스 트랜잭션은 트랜잭션 구현을 저장프로시저에서 수행함으로써, 클라이언트와 오직 단 한번의

라운드 트립만이 발생하며, 가장 빠른 성능을 제공한다. 하지만, Transact SQL 을 사용하여 구현해야 하며, 쿼리 문장들을 단일하게 사용하기 위해서는 일일이 코딩을 해 주어야 한다 라는 번거로움을 가진다.필요에 따라서 계속해서 추가적인 저장 프로시저를 작성해 주어야 하며, 애플리케이션이 점점 커짐에 따라서

저장프로시저의 관리가 복잡해 진다는 단점을 가진다. ADO.NET 수동 트랜잭션

ADO.NET 의 수동 트랜잭션의 구현은 저장프로시저를 사용한 구현보다 많은 라운드 트립이 발생하며, 데이터베이스를 사용한 트랜잭션 구현 보다 성능 측면에서 성능이 떨어진다. 모든 쿼리문장들을

150


코드레벨에서 관리해 주어야 하며, 모든 트랜잭션 관리 및 리소스 관리들을 개발자가 수동으로 처리해야 하는

부담을 가진다. 개발자의 실수로 인하여 정확한 작업이 이루어 지지 못하는 경우가 발생할 수 있다. 또한

트랜잭션 없이 쿼리를 수행해야 할 경우에는 개발자가 추가적으로 해당 쿼리에 대한 작업을 재 작성해야 하는

번거로움을 가진다. COM+ 서비스를 이용한 자동 트랜잭션

성능 측면에서는 가장 떨어지는 방식이다. 모든 트랜잭션에 관련한 사항들을 COM+ / DTC 에 의해서

관리하도록 지정한다. 자동 트랜잭션 방식은 개발자가 내부에서 트랜잭션에 대한 관리 부담이 적을 뿐더러, 분산 트랜잭션 관리에 있어서도 손쉽게 재 배치 구현할 수 있는 장점을 가진다. 또한 원하는 쿼리에 있어서도

모두 단일한 쿼리 단위로 구성되어 있으므로, 재 사용이 가능하여 애플리케이션 개발간의 재사용성을 높이는

결과를 가져오게 된다. 성능적인 측면에서는 가장 떨어지지만, 개발 생산성적인 측면 및 확장성 측면에서

가장 우위를 가지게 된다.

위의 세가지 옵션들의 Trade-Off를 중심으로 살펴본 결과를 보아도 알 수 있듯, COM+ 서비스를

사용한 애플리케이션 내에서의 Transaction 관리가 개발 시에 윌등한 우위를 보임을 알 수 있을

것이다. 약간의 성능저하 문제는 머신의 성능 향상을 통하여 극복이 가능한 문제이지만, 근본적인

구조적 문제, 혹은 개발 생산성 문제는 이 보다 더 커다란 문제가 될 수 있다.

151


[그림 52] 트랜잭션 옵션별 성능 비교

위의 비교 그래프는 다양한 트랜잭션관리 옵션들을 구현하여 비교한 성능 그래프 이다. 각각

DatabaseTxn / ManualTxn / AutoCompleteTxn_IP 에 대한 구현 그래프들을 유심히

살펴보길 바란다. DxFrameworkLite에서는 이 세가지의 옵션들 중에서 COM+ 서비스를 사용한 자동 트랜잭션

관리를 사용하고 있다.

3.3.8.7. DxFrameworkLite에서의 트랜잭션 관리

DxFrameworkLite에서 권장하는 트랜잭션 관리 방법은 앞서 설명 했듯 COM+ 서비스를 이용한

자동 트랜잭션 관리이다.

3.3.8.7.1. AutoComplete의 사용

명시적으로 ContextUtil 을 이용한 SetComplete 혹은 SetAbort를 구현하는 것은 마치 우리가

앞서 살펴본 ADO.NET 의 매뉴얼 트랜잭션의 경우에서처럼 Try/ Catch/ Finally 코드 모델을

통하여 구현해야 하며, 개발자가 일일이 오류 처리에 대한 코딩을 해 주어야 하는 번거로움을

가지며, 이로 인하여 개발자들 간에 일관성 있는 처리를 기대하기 어렵게 된다는 단점이 있다. 또한 JustInTimeActivation인 경우, 명시적으로 SetComplete를 호출하지 않으면 Deactivate 이벤트가 발생하지 않는다.AutoComplete 인 경우, 해당하는 메소드가 오류가 발생하였는지 여부에 따라서 자동적으로

트랜잭션에 대해서 Commit을 수행하며, 오류가 발생하면 Rollback을 수행한다. 또한

JustInTimeActivation의 경우 메소드 수행이 끝나면 자동으로 Deactivate 이벤트가 발생한다.DxFrameworkLite에서는 COM+ 애플리케이션 구현간에는 모두 AutoComplete의 사용을

권장한다. 모든 메소드 간의 오류 처리는 글로벌 한 오류 처리 개체에 의해서 처리되며, 개발자들은 개별적인 오류 처리를 할 필요가 없다. 그렇기 때문에 비니지스 룰에 의한 명시적인

SetComplete 혹은 SetAbort 를 호출하는 이외의 명시적으로 SetComplete 혹은 SetAbort 를

호출할 필요가 없다.

3.3.8.7.2. DxFrameworkLite에서 트랜잭션 구현

DxFrameworkLite를 사용하여 Business Class 와 Data Access Class를 구현하기 위해서는

Data Access의 구현을 간편하게 해 주기 위해 DBAgent를 사용한다. 이러한 클래스 들을 구현

하기 위해서는 간단히 어떻게 각각의 클래스들의 트랜잭션 옵션들을 구현해 주어야 하는지에

대한 이해가 필요하다.

152


[그림 53] 트랜잭션 구현

위의 그림은 DxFrameworkLite를 통하여 COM+ 서비스를 사용하는 클래스들간의 트랜잭션

옵션을 통한 트랜잭션의 구현을 도식화 한 그림이다.위의 그림에서 보면 클라이언트는 Business Object(Tx)를 호출한다(Tx : Transaction Required 를 뜻한다). Business Object(Tx)는 Business Object(nTx)를 호출하거나 직접

Data Access Object를 호출하며, Data Access Object는 DBAgent를 호출하여

데이터베이스에 엑세스 한다.그림에서 보듯, 이 클래스들은 Business Object(Tx)가 생성한 트랜잭션 내부에서 생성되며

하나의 단일한 트랜잭션 내에서 작업이 진행됨을 알 수 있다.때에 따라서 위의 그림은 비즈니스 로직의 복잡도에 따라서 클래스가 추가되거나 생략 될 수 도

있다.일반적인 경우에 있어서, Business Object nTx가 없이 클라이언트는 필요에 따라서는 Data Access Object를 직접 호출 할 수 도 있다. 이러한 경우에 각각의 Data Access 에 존재하는 DB Query 들은 DTC 의 트랜잭션 Context를 생성하지 않고 곧장 Query를 실행할 수 있다. 트랜잭션이 필요 없는 쿼리에 경우 불필요 하게 DTC 내부의 부하를 거칠 필요가 없기 때문에

성능의 향상을 가지고 올 수 있다.또한, 구조에 따라서는 Data Access 객체와 Business 객체가 물리적으로 다른 Box 에 위치될

경우에는 Business Object nTx 컴포넌트를 통하여 Data Access Object를 호출, 위에서

구현했던 것 과 동일하게 DTC 의 부하 없이 Query를 수행할 수 있으며, DTC 에 의해서

Transaction 을 구현해야 할 필요가 있을 경우에만 Business Object (Tx)를 호출하면 되는

구조를 가지게 된다.

153


위의 그림을 통하여 트랜잭션을 구현하는 방식을 이해하고 DxFrameworkLite에서 제공하는

샘플을 살펴보게 되면 보다 쉽게 트랜잭션을 구현하는 방식에 대한 이해를 할 수 있게 될 것이다.

3.3.8.8. 결론

.NET Framework 에서 구현할 수 있는 트랜잭션 옵션에는 크게 3가지로 나뉘며, 그 구현에

있어서는 개발의 필요에 따라서, 그 아키텍처에 따라서 달라질 수 있다. 하지만

DxFrameworkLite에서는 개발자들이 개발 하는 데 있어서 보다 생산성 높으며, 확장성 뛰어난

옵션을 가지고 있는 COM+ 서비스를 이용한 트랜잭션 관리를 사용하고 있다. 이는 성능적인 측면

보다, 개발자들이 손쉽게 개발하면서도 오류를 범하지 않으며, 일관성 있는 애플리케이션 개발을

가능케 하고, 애플리케이션의 확장을 보다 손쉽게 하기 위해서 임을 알 수 있다.

3.3.9. 예외 처리

이 장에서는 DxFrameworkLite를 활용하여 .NET N-Tier 애플리케이션을 개발할 때, 예외를

적절하게 관리하기 위한 방법에 대해서 설명한다. 애플리케이션을 개발할 때 발생하는 컴파일

오류를 제거하는 것도 중요하지만, 런타임 시에도 예상치 못한 예외가 발생할 수도 있으므로 그에

대한 적절한 대처 및 처리 방법을 수립해 놓는 것이 중요하다.

3.3.9.1. 예외처리와 관련한 일반적 사항3.3.9.1.1. 예외처리 과정

예외는 다음과 같이 크게 두가지 단계로 나누어서 볼 수 있다. 그림 2-1은 어떤 메서드 내에서

예외가 발생했을 때의 상황이다. 먼저 이 예외를 탐지하는 try~catch 절이 있는지를 판단해

본다. 만약 try~catch 절이 없으면, 메서드의 호출자(caller)로 예외가 전달된다. try~catch 절이 있다면, catch 절 내에서 예외를 필터링한 후 이 예외를 어떻게 처리할 것인가를 결정하게

된다. 만약 이 예외가 복구 가능한 예외라면, 복구에 필요한 처리를 수행하고 예외를 소멸시킨 후

계속 코드를 수행한다. 이 예외가 복구 불가능한 예외라면, 특정한 일을 수행한 후 호출자에게

다시 예외를 전달한다.

154


[그림 54] 예외처리 [그림 55] Unhandled Exception 처리

그림 2.2.7-2는 2.2.7-1의 과정을 거친 후 전달된 예외를 보여주고 있다. 발생한 시점에서

처리되지 않고 호출자에게 전달된 예외를 Unhandled Exception이라고 부른다. Unhandled Exception은 일반적으로 최상단의 전역 예외 처리기에서 검출되어, 로그로 기록한 후

사용자에게 예외에 관련한 정보를 표시하는 형태로 처리된다.

3.3.9.1.2. 예외 탐지

예외가 발생했는지를 검출하고, 이를 처리하기 위해서는 try, catch, finally 문을 사용한다. 각각에 대한 자세한 설명은 .NET Framework 문서를 참조한다.

//C#try{ // 예외가 발생가능한 프로그래밍 로직

}catch (SomeException exc)

{

155


// 예외 발생 시 처리할 코드

}finally{ // 예외 발생 여부에 관계없이 항상 실행되는 코드

// 보통 Clean-up 코드가 들어간다.}

‘VB.netTry

‘예외가 발생 가능한 프로그래밍 로직

Catch ex as SomeException‘예외 발생 시 처리할 코드

Finally‘예외 발생 여부에 관계없이 항상 실행되는 코드

‘보통 Clean up 코드가 들어간다

End Trytry, catch, finally 사용 시의 가이드 라인은 다음과 같다.

특정 메서드 내용 전체를 try로 감싸지 않는다. 예외가 발생할 가능성이 없는 코드는 try 블록 밖으로 빼고, 가능한 한 try 블록을

간결하게 만든다. 가능한 한 특정한 예외와 일반적인 예외를 구분해서 별도의 catch 블록으로 잡는다. catch 절은 상세한 하위 예외를 먼저, 일반적인 상위 예외를 나중에 잡도록 배치한다. 아무것도 하지 않는 catch 절의 작성을 피한다. 예외 발생 여부에 관계없이 항상 실행되어야 하는 코드는 finally 블록에 작성한다. try, catch, finally에서 모두 사용되어야 하는 변수는 try 블록 위에 선언한다.

다음은 프로그래머들이 흔히 하기 쉬운 실수 중 하나를 든 예이다.잘못된 사용 예 올바른 사용 예

//C#try {string strQuery = "INSERT INTO … ";…OracleConnection conn =

//c#string strQuery = "INSERT INTO … ";OracleConnection conn = new OracleConnection();…

156


new OracleConnection();…conn.Open();OracleCommand cmd = new OracleCommand();…conn.Close();}catch {}

‘VB.netTry

Dim strQuery as String = “Insert Into..”

…Dim conn as new

OracleConnection()conn.OpenDim cmd as new

OracleCommand()…Conn.Close

CatchEnd Try

try {…conn.Open();OracleCommand cmd = new OracleCommand();…}catch (OracleException ex) {WriteLog(ex);…}catch (Exception ex) {WriteLog(ex);…}finally {conn.Close();}

‘VB.netDim strQuery as String = “Insert Into..”Dim conn as new OracleConnection()...

Try…conn.Open()Dim cmd as new OracleCommand()…

Catch ex as OracleExceptionWriteLog(ex)…

Finallyconn.Close()

End Try

157


그리고 catch에 전달되는 Exception의 경우, 원래의 예외를 CLR이 가로채서 다른 예외로

Wrapping해서 발생시킬 수도 있다. Wrapping 된 예외는 정확하지 않거나, 원래의 의미를

감춰버리기 때문에 혼동이 올 수 있는데, 이 경우 InnerException을 살펴보면 원래의 예외를 알

수 있다.

3.3.9.1.3. 예외 전달

예외가 발생했을 때, 이를 전달하는 방법은 크게 4가지가 있다. 예외가 자동으로 전달되도록 내버려 둔다.

이 경우, 발생한 예외 형과 일치하는 catch 필터를 만날 때까지, 호출 스택 상으로 계속

올라가게 된다. 만약 catch 블록이 없으면, Unhandled Exception 처리기까지 전달된다. 일반적으로 업무용 분산 애플리케이션 개발 시, 권장되는 방법이다.

catch 한 후, rethrow 한다.예외를 catch 한 후, 어떤 처리를 수행하고 예외를 rethrow한다. 업무용 분산

애플리케이션 개발 시에 이 방법은 별로 잘 사용되지 않는다. catch 한 후, Wrapping된 새로운 예외를 throw한다.

예외를 catch 한 후, 어떤 처리를 수행하고 좀 더 구체적인 의미 또는 사용자 정의 예외로

Wrapping해서 throw한다. 업무용 분산 애플리케이션 개발 시에 자주 사용되는 방법 중

하나로, 원래의 예외는 로그로 기록하고, 사용자에게 보여주기 위한 오류 메시지로

변환해서 보내게 된다. catch 한 후, 예외를 throw하지 않는다.

catch 한 후, 어떤 처리를 통해서 복구가능하거나 예외를 무시해버리고 싶은 경우에

사용한다. 과거 VB에서 On Error Resume 구문을 사용하는 것과 비슷하다고 할 수 있다. 예외를 무시해버리는 것은 반드시 필요한 상황이 아니라면, 가급적 사용하지 않는 것이

좋다.

[그림 56] 예외의 전달

3.3.9.2. 사용자 정의 예외

기본적으로 제공되는 .NET Framework의 예외에 보다 명확한 의미를 부여하고 싶거나,

158


자신만의 새로운 예외를 제공하고 싶은 경우에는 Exception 또는 ApplicationException에서

상속받은 사용자 정의 예외를 정의한다.

[그림 57] 예외 계층 구조

기본적으로 Exception 클래스는 여러 개의 생성자 오버로딩을 지원하므로, 거기에 맞춰서

사용자 정의 예외 클래스에도 생성자 오버로딩을 정의해 주는 것이 좋다. 그리고, .NET Remoting을 통해서 사용자 정의 예외를 전달할 수 있게 하려면, 클래스 정의에 [Serializable] 특성을 붙이고 SerializationInfo, StreamingContext 매개변수를 받는 생성자를 추가로

정의해야 한다. 사용자 정의 예외에 필드를 추가했다면, 데이터 스트림을 직렬화하기 위해

GetObjectData 메서드를 재정의해야 한다.위 내용대로 만든 사용자 정의 예외 클래스의 예는 다음과 같다.

//C#[Serializable]public class ExampleException : ApplicationException{ public ExampleException() : base() { } public ExampleException(string message) : base(message) { } public ExampleException(string message,Exception inner) :

159


base(message,inner) { } protected ExampleException(SerializationInfo info, StreamingContext context) : base(info,context) { m_strMachineName = info.GetString("m_strMachineName"); }

public override void GetObjectData( SerializationInfo info, StreamingContext context ) { info.AddValue("m_strMachineName", m_strMachineName, typeof(String));

base.GetObjectData(info,context); }

private string m_strMachineName = Environment.MachineName;

public string MachineName { get { return m_strMachineName; } set { m_strMachineName = value; } }}

‘VB.net<Serializable> _Public Class ExampleException : Inherits ApplicationException

160


Public Sub New()MyBase.New()

End Sub

Public Sub New(ByVal message As String)MyBase.New(message)

End Sub

Public Sub New(ByVal message As String, ByVal innerException As Exception)MyBase.New(message, innerException)

End Sub

Public Sub New(ByVal info As SerializationInfo, ByVal context As StreamingContext)

MyBase.New(info, context)m_strMachineName = info.GetString("m_strMachineName")

End Sub

Public Overrides Sub GetObjectData(ByVal info As SerializationInfo, _ ByVal context As StreamingContext)

info.AddValue("m_strMachineName", m_strMachineName, GetType(String))

MyBase.GetObjectData(info, context)End Sub

Private m_strMachineName As String = Environment.MachineName

Public Property MachineName() As StringGet

Return m_strMachineNameEnd GetSet(ByVal Value As String)

m_strMachineName = ValueEnd Set

End PropertyEnd Class

161


3.3.9.3. Unhandled Exception 관리

일반적으로 웹 애플리케이션에서는 최종 Tier인 ASP.NET에서 Unhandled Exception을

관리하게 된다. 기본적으로 ASP.NET에서는 Unhandled Exception이 발생했을 때, 브라우저에

오류 페이지를 보여주도록 되어 있다. ASP.NET에서 Unhandled Exception을 관리하는 방법은

몇 가지 방법이 존재하는데, 이들에 대해서 알아보도록 하자.

3.3.9.3.1. Web.config

다음과 같이 Web.config의 customErrors 섹션을 설정하여 Unhandled Exception을 처리할

수 있다.

<customErrors defaultredirect="http://hostname/error.aspx" mode="on"> <error statuscode="500" redirect="/errorpages/servererror.aspx" /> <error statuscode="404" redirect="/errorpages/filenotfound.htm" /></customErrors>customErrors의 내용 및 구문에 대해서는 web.config의 주석 또는 .NET Framework SDK 문서를 참조한다. 위 예제대로 특정 HTTP 에러 코드에 대해 반응하거나, 전역적인 디폴트 설정을

할 수 있다. 참고로 이 설정은 ASP.NET 파일(*.aspx, *.ascx, *.asmx 등)에만 유효하며, *.asp나 *.htm 파일 등에는 해당되지 않는다(이 파일들은 IIS 설정을 따른다).Web.config를 통해 처리하는 것은 간편하기는 하나, 너무 추상적이며 예외 정보에 접근하기

불편하므로 권장되지 않는다. 가급적이면 HTTP 오류에 대한 처리로만 사용하는 것이 좋다.

3.3.9.3.2. @Page 지시자

다음과 같이 각 페이지의 Page 지시자 내에 ErrorPage 어트리뷰트를 설정할 수도 있다. 이

설정은 Web.config의 설정보다 우선한다.

<%@ Page ErrorPage="customerror.aspx" %>

3.3.9.3.3. Page_Error

ASP.NET 웹 폼 클래스(Page)는 예외가 발생 또는 전달되면, Error 이벤트를 발생시킨다. 이

이벤트에 대한 핸들러를 등록해서 Unhandled Exception을 처리할 수 있다. 예외가 발생했을

때, Page 내의 개체에 접근할 필요가 있다면 이 이벤트를 잡는 것이 좋다. 웹 폼 부모 클래스에서

Page_Error를 정의하여, Unhandled Exception으로 처리하는게 바람직하다.

3.3.9.3.4. Application_Error

global.asax 파일 내에 작성하며 애플리케이션 전역에서 발생한 Unhandled Exception을 잡을

162


수 있다. Page_Error 이후에 발생된다. 이 이벤트 핸들러 내에서 에러를 로그로 기록하거나, 필요한 정리동작 등을 수행할 수 있다. ASP.NET 사용 시에 권장되는 Unhandled Exception 처리 방법이다. Server.GetLastError를 사용하여 Unhandled Exception 개체를 가져올 수도

있으며, Server.ClearError를 호출하여 Unhandled Exception을 소멸시킬 수도 있다.

3.3.9.4. N Tier 개발 시 예외 처리 전략

이상적으로는 예외 처리를 철저하고 꼼꼼하게 작성하는 것이 바람직하지만, 이렇게 될 경우 실제

프로그래밍 로직을 작성하는데 걸리는 시간보다, 예외 처리에 시간을 더 많이 보내게 된다. 또한, 애플리케이션을 개발할 때 개발자가 모든 예외에 대해 사전에 파악해서 처리한다는 것은 사실상

불가능하다. 하지만 그렇다고 모든 예외에 대해 대처를 하지 않으면 사용자가 시스템의 예외

메시지에 그대로 노출되게 된다.그러므로 예외 처리를 하는데 들어가는 시간과 노력을 최소화하면서 최대의 효과를 얻을 수 있는

방법을 제공하여, 개발 생산성과 애플리케이션의 견고성을 동시에 가질 수 있도록 해야 한다.이번 절에서는 위의 일반적인 사항을 바탕으로 최소 노력으로 최대 효과를 얻기 위한 예외 처리

방안을 제시하고자 한다.

3.3.9.4.1. 기본 개념

DxFrameworkLite 사용 시의 예외 처리 시 기본 개념은 예외가 발생하면 그대로 혹은 rethrow 한다는 것이다. 대신 각 Tier에서 각 Tier의 역할 별로 필요한 Clean-up 코드는 try~catch 문을

활용하는 대신에 COM+의 Just-In-Time Activatation (JITA)의 특성을 최대로 활용하여, Deactivate에서 무조건 Clean-up 코드를 호출하도록 하는 형태로 설계하였다. 그리고, 최종적인 예외의 로그 기록과 같은 동작은 전역 예외 핸들러에서 처리하도록 처리하도록 하였다.

163


User ServiceUser Service

Business FacadeBusiness Facade

Data Data AcessAcess

Business RulesBusiness Rules

오류처리오류처리 및및 기록기록

EventEventLogLog

Text Text FileFile

TraceTraceUtilUtil

.ASPX.ASPX Global.asaxGlobal.asax((Application_ErrorApplication_Error))

rethrow(AutoCompleterethrow(AutoComplete))

rethrow(AutoCompleterethrow(AutoComplete))

[그림 58] 예외 처리 과정

3.3.9.4.2. Business Logic Layer의 예외 처리

Business Logic Layer에서 예외가 발생했을 경우, 일반적으로 다음과 같은 작업을 수행한다.

트랜잭션 내에 포함되어 있으면, 트랜잭션을 취소하고 롤백(RollBack)한다. DB Connection이 열려 있으면 닫히도록 보장한다(자원의 해제). 에러 로그를 기록한다.

예외가 발생하지 않았을 경우, 트랜잭션을 커밋(Commit)하고 호출을 반환하게 된다.이러한 작업을 try~catch 문을 사용해서 작업할 경우 Business Logic 컴포넌트의 메서드는

다음과 같다(COM+ 분산 트랜잭션을 사용한다고 가정).

//C#[Transaction(TransactionOption.Required), JustInTimeActivation(true)]public class TestDac : ServicedComponent {public void AddNewData(…) {string strQuery = "INSERT INTO … ";SqlConnection conn = new SqlConnection();…try {

164


conn.Open();SqlCommand cmd = new SqlCommand(strQuery, conn);cmd.ExecuteNonQuery();ContextUtil.SetComplete(); // 트랜잭션을 수행

}catch (Exception ex) {ContextUtil.SetAbort(); // 트랜잭션을 취소

WriteLog(ex); // 에러 로그를 기록

}finally {

conn.Close(); // Connection을 닫는다.}}}

‘VB.net

<Transaction(TransactionOption.Required), JustInTimeActivation(True)> _Public Class TestDac Inherits ServicedComponent Public Sub AddNewData() Dim strQuery As String = "INSERT INTO … " 'Dim conn As New SqlConnection()…. Try conn.Open() Dim cmd As New SqlCommand(strQuery, conn) cmd.ExecuteNonQuery() ContextUtil.SetComplete() ' 트랜잭션을 수행

Catch ex As Exception ContextUtil.SetAbort() ' 트랜잭션을 취소

WriteLog(ex) ' 에러 로그를 기록

Finally conn.Close() ' Connection을 닫는다.

End Try End Sub

165


End Class위 예에서 볼 수 있듯이 try, catch 및 finally 절이 계속 반복적인 코드로 나타난다는 것을 알 수

있다. 이 때문에 발생가능한 문제점들은 다음과 같다.

불필요한 코드가 반복되어 생산성이 저하된다. 예외처리를 하지 않을 때에 비해 코드의 가독성이 떨어진다. try~catch 수행으로 인해 성능이 저하된다. 개발자가 실수로 누락 시킬 수 있다.

이러한 문제점들을 해결하면서도 동일한 효과를 보장하기 위해서 다음과 같은 방안이 제시된다.

트랜잭션 여부에 관계없이 모든 메서드에 [AutoComplete] 특성을 붙인다. AutoComplete이 해주는 역할은 크게 2가지인데, 첫째는 메서드 내부에서 예외가

발생했는지 여부에 따라 자동적으로 트랜잭션을 수행 또는 취소한다. 둘째로 메서드

내부에서 예외가 발생하더라도 Deactivate가 호출되는 것을 보장한다. AutoComplete이

없으면, 예외 발생 시 Deactivate가 호출되는 것이 보장되지 않는다. Deactivate에서 DB 연결을 닫는 코드를 작성한다.

즉, 어떤 상황이 되더라도 Deactivate가 호출되면 DB 연결이 닫히도록 보장된다. 로그 기록은 전역 예외 처리기를 활용한다. 자세한 사항은 다음 절을 참조한다. 예외는 그대로 내버려 두거나 rethrow 한다. 반드시 필요한 경우가 아니면, Business Logic에는 절대 try~catch 문을 작성하지 않는다.

AutoComplete을 적용하면, 위의 메서드는 다음과 같이 작성될 수 있다(DbAgent 사용을 가정). TestDac의 AddNewData 메서드가 매우 간결해졌다는 것을 알 수 있다.

//C#[Transaction(TransactionOption.Required), JustInTimeActivation(true)]public class TestDac : DacBase {[AutoComplete]public void AddNewData(…) {string strQuery = "INSERT INTO … ";_agent.ExecuteNonQuery(strQuery, …);}}

166


public class DacBase : ServicedComponent { protected SqlDbAgent _agent; protected string _connectionString = null;

public DacBase() { }

// 메서드가 호출되기 전에 자동으로 호출된다. // 멤버변수 _agent를 초기화한다. protected override void Activate() { _agent = new SqlDbAgent(); … }

// 메서드가 호출된 후 자동으로 호출된다. // 멤버변수 _agent를 정리한다(내부에서 Connection을 Close) protected override void Deactivate() { if ( _agent != null ) { ServicedComponent.DisposeObject(_agent); _agent = null; } }}‘VB.net<Transaction(TransactionOption.Required), JustInTimeActivation(True)> _Public Class TestDac : Inherits DacBase <AutoComplete()> _ Public Sub AddNewData() Dim strQuery As String = "INSERT INTO … "

_agent.ExecuteNonQuery(strQuery) End SubEnd Class

167


_

Public Class DacBase : Inherits ServicedComponent Protected _agent As SqlDbAgent Protected _connectionString As String = Nothing ' 메서드가 호출되기 전에 자동으로 호출된다. ' 멤버변수 _agent를 초기화한다. Protected Overrides Sub Activate() _agent = New SqlDbAgent() End Sub

' 메서드가 호출된 후 자동으로 호출된다. ' 멤버변수 _agent를 정리한다(내부에서 Connection을 Close) Protected Overrides Sub Deactivate() If Not (_agent Is Nothing) Then ServicedComponent.DisposeObject(_agent) _agent = Nothing End If End Sub End Class

3.3.9.4.3. Presentation Layer에서의 예외처리

Presentation Layer는 Layer의 마지막에 위치하므로, 위치의 특성 상 프로그래머가 이전 Layer에서 발생한 예외를 처리할 수 있는 마지막 위치이기도 하다. 또한 Presentation Layer 자체의

코드 상에서도 예외가 발생할 수 있으므로, 이 두 가지를 구분해서 설명하도록 하겠다.

Presentation Layer에서 발생된 예외

Presentation Layer 자체에서 발생되는 예외는 사용자 인터페이스와 관련된 예외이므로, 가급적이면 예외가 발생하지 않게 하는 것이 더욱 바람직하다. 또한 특성 상 에러를 복구할 수

있는 방법이나 Clean-up 코드가 필요 없는 경우가 대부분이므로 예외 처리 코드가 불필요한

경우가 많다.사용자 입장에서도 인터페이스 조작 시의 오류에 의한 메시지가 뜨는 것보다는 아예

바람직한 조작만 할 수 있도록 강제해 주는 것이 더욱 편리하다. 사용자 인터페이스 상에서

예외 발생을 방지할 수 있는 방법은 다음과 같다.

168


컨트롤의 Visible, Enable 속성을 적절히 제어한다. Validation 컨트롤을 활용한다. 클라이언트 스크립트 또는 HTC를 활용한다. Unhandled Exception은 Page_Errr 나 Application_Error에서 처리하도록 한다

그러나, 위에서도 언급했듯 예외는 가급적 발생하지 않도록 미연에 방지하는 것이 좋다는 것에

유의하자.

이전 Layer에서 발생되어 전달된 예외

이전 Layer에서 발생한 예외는 Presentation Layer에서 사용자에게 친숙한 에러 메시지로

변환해서 보여주는 것이 바람직하다. 예를 들어, DB에 신규 사용자를 Insert하는 동안 중복 키

오류가 발생했을 때, ‘Primary Key가 중복되었습니다’라는 메시지 보다는 ‘사용자가 이미

존재합니다’와 같은 오류 메시지를 표시하는 것이 사용자에게 보다 명확한 의미를 전달할 수 있다.이를 위해서는 다음과 같이 발생한 예외를 사용자 정의 예외로 Wrapping 한 다음에 rethrow하는 것이 바람직하다.

//C#private void Button1_Click(object sender, System.EventArgs e) {UserSystem userSystem = new UserSystem(); try {userSystem.AddUser(_inputPack);}catch (OracleException ex) {// 예외 파싱

…throw new DuplicatedDataException("사용자가 이미 존재합니다", ex);}}

‘VB.netPrivate Sub Button1_Click(sender As Object, e As System.EventArgs) Dim userSystem As New UserSystem() Try userSystem.AddUser(_inputPack) Catch ex As OracleException ' 예외 파싱

169


…. Throw New DuplicatedDataException("사용자가 이미 존재합니다", ex) 'End TryEnd Sub 'Button1_Click

여기서는 catch 절에서 OracleException 예외 메시지를 파싱해서 전달하도록 되어 있는데, 사용자 정의 예외 클래스를 잘 디자인하여 내부에 이러한 파싱로직을 만들어도 된다.

3.3.9.4.4. Unhandled Exception의 처리

위에서 언급했듯이 Unhandled Exception은 Page_Error 또는 Application_Error 중 하나를

선택해서 보통 처리하게 된다. 이벤트는 Page_Error -> Application_Error 순으로 발생된다.

Page_Error

Unhandled Exception을 처리 시에 Page 개체에 접근할 필요가 있는 경우에 사용한다.각 페이지의 웹 폼 클래스에 Page_Error을 정의하고 작성해도 되지만, Unhandled Exception을

통해 공통적으로 처리하는 것이므로 웹 폼 클래스의 부모 클래스에 정의해두고, 각 웹 폼

클래스가 이를 상속받는 구조로 만드는 것이 바람직하다. 발생한 예외를 가져오려면, HttpContext.Current.Error 또는 Server.GetLastError를 사용한다.Page의 Error 이벤트를 핸들링하려면, 다음과 같이 Error 이벤트에 대한 이벤트 핸들러를

만들거나 OnError 메서드를 재정의하면 된다.

//C#using DxFrameworkLite.Diagnostics; // ErrorLog 클래스를 사용하기 위해

public class WebFormBase : System.Web.UI.Page {…override protected void OnInit(EventArgs e){InitializeComponent();base.OnInit(e);}

private void InitializeComponent(){Page.Error += new System.EventHandler(Page_Error);…}

170


protected void Page_Error(Object sender, EventArgs e) {if (HttpContext.Current.Error != null) {// 발생한 예외를 가져옴

System.Exception ex = HttpContext.Current.Error;// 에러 로그를 남김

ErrorLog errorLog = new ErrorLog("Error", "MyApplication", Request.PhysicalApplicationPath + @"log\error.log");

// 사용자 정의 예외이면, InnerException(원래의 예외)을 기록

if (ex is MyException) {errorLog.WriteExceptionLog(ex.InnerException);

string errorMsg = HttpContext.Current.Error.Message;

// ErrorDialog를 띄움

ModalDialog modalDialog = new ModalDialog();modalDialog.DialogUrl = Request.ApplicationPath + "/ErrorDialog.aspx";modalDialog.Parameters.Add("ex", errorMsg);modalDialog.ShowModal();

HtmlTextWriter writer = new HtmlTextWriter(Response.Output);

Response.Write("<HTML><BODY>");modalDialog.RenderControl(writer);Response.Write("</BODY></HTML>");

// HttpContext에서 예외 정보를 삭제

HttpContext.Current.ClearError();}else{

errorLog.WriteExceptionLog(ex);

171


}}}}

‘VB.netImports DxFrameworkLite.Diagnostics ' ErrorLog 클래스를 사용하기 위해

Public Class WebFormBase : Inherits System.Web.UI.Page Protected Overrides Sub OnInit(e As EventArgs) ' .... InitializeComponent() MyBase.OnInit(e) End Sub Protected Sub Page_Error(sender As [Object], e As EventArgs) If Not (HttpContext.Current.Error Is Nothing) Then ' 발생한 예외를 가져옴

Dim ex As System.Exception = HttpContext.Current.Error ' 에러 로그를 남김

Dim errorLog As New ErrorLog("Error", "MyApplication", _ Request.PhysicalApplicationPath + "") ' 사용자 정의 예외이면, InnerException(원래의 예외)을 기록

If TypeOf ex Is MyException Then errorLog.WriteExceptionLog(ex.InnerException) Dim errorMsg As String = HttpContext.Current.Error.Message ' ErrorDialog를 띄움

Dim modalDialog As New ModalDialog() modalDialog.DialogUrl = Request.ApplicationPath + "/ErrorDialog.aspx" modalDialog.Parameters.Add("ex", errorMsg) modalDialog.ShowModal() Dim writer As New HtmlTextWriter(Response.Output) Response.Write("<HTML><BODY>")

172


modalDialog.RenderControl(writer) Response.Write("</BODY></HTML>") ' HttpContext에서 예외 정보를 삭제

HttpContext.Current.ClearError() Else errorLog.WriteExceptionLog(ex) End If End If End SubEnd Class

위 코드에서는 Page_Error에서 MyException(사용자 정의 예외의 기반 클래스로 가정) 또는

MyException에서 파생된 사용자 정의 예외가 들어오는 경우, Wrapping되기 이전의 원래

예외인 InnerException을 로그로 기록하고, 사용자 정의 예외를 ModalDialog 창을 통해 띄운

후, ClearError로 예외 정보를 삭제하여 예외가 더 이상 전달되지 않게 한다. 만약 사용자 정의

예외가 아니면, 예외 그대로 로그로 기록된다. ModalDialog로 띄우는 것은 사용자 정의 예외

메시지를 표시하는 예에 불과하므로, 참고만 하기 바란다.각 웹 폼 클래스가 이 WebFormBase라는 클래스를 상속받도록 구현하면, Unhandled Exception 처리 메커니즘을 상속받게 된다.

Application_Error

Unhandled Exception을 처리할 때 가장 권장되는 방법으로, Global.asax 내에서 정의한다. 작성하는 방법은 Page_Error 때와 거의 유사하다. 단, 여기서는 Page 개체와 어떤 연관관계를

가질 수 없다는 것에 주의하기 바란다. 다음은 DxFrameworkLite의 엔터프라이즈 템플릿을

사용했을 때 Global.asax의 Application_Error의 내용이다. Unhandled Exception이 발생했을

때 Custom Error 페이지로 Transfer 시키도록 작성되어 있다.

//C#protected void Application_Error(Object sender, EventArgs e){Exception ex = ( HttpContext.Current.Error.InnerException == null ? HttpContext.Current.Error : HttpContext.Current.Error.InnerException );

string errorMsg = EventLog.FormatException(ex);

173


EventLog.WriteErrorLog( errorMsg );

HttpContext.Current.Items[ "ErrorMessage" ] = errorMsg;

AppSettingsReader reader = new AppSettingsReader("DxApplication/CustomError"); string url = DxSamples.ApplicationFramework.Global.ApplicationPath + reader["TransferForm"];

Server.Transfer( url );}

‘VB.netProtected Sub Application_Error(sender As [Object], e As EventArgs) Dim ex As Exception = _ IIf((HttpContext.Current.Error.InnerException Is Nothing), _ HttpContext.Current.Error,HttpContext.Current.Error.InnerException)) Dim errorMsg As String = EventLog.FormatException(ex) EventLog.WriteErrorLog(errorMsg) HttpContext.Current.Items("ErrorMessage") = errorMsg Dim reader As New AppSettingsReader("DxApplication/CustomError") Dim url As String = DxSamples.ApplicationFramework.Global.ApplicationPath + _ reader("TransferForm") Server.Transfer(url)End Sub

3.3.9.5. 예외 정보 수집 및 로그

예외를 어떻게 남길 것인가에 대한 방법적인 요소들은 이전에 논의되었다. 그러나 방법도

중요하지만, 무엇을 정보로 남길 것인지도 매우 중요하다. 이번 절에는 예외로 남겨야 하는

정보와 로그로 기록하는 방법들에 대해서 알아보도록 하겠다.

3.3.9.5.1. 예외 정보 수집

예외 정보를 기록할 때, 어떤 내용을 남길 것인지 결정하는 것이 중요하다. 예외 정보는

사용자에게 보여주기 위한 메시지가 될 수도 있고, 개발자가 디버깅을 하기 위한 수단이 될 수도

있으며, 운영자가 문제점을 찾고 복구하기 위한 근거가 될 수도 있다. 예외 정보를 필요로 하는 각

대상과 이들에게 필요한 정보를 요약해보면 다음과 같다.

174


대상 필요한 정보

일반 사용자 자신의 요청(동작)이 성공했는지 아닌지 여부무엇이 잘못되었는지를 알려주는 잘 꾸며진 메시지문제를 해결하기 위해서 어떻게 해야 하는지에 대한 지시사항

개발자 예외가 발생한 날짜 및 시간예외가 발생한 정확한 위치(소스코드)발생한 예외의 정확한 종류예외 및 예외가 발생할 때의 시스템 상태에 관한 정보

운영자 예외가 발생한 날짜 및 시간예외가 발생한 정확한 위치(모듈)발생한 예외의 정확한 종류운영 상의 문제인지 코드 상의 버그인지를 구분할 수 있게 해주는 정보

이를 위해 .NET Framework에서 제공하는 기본적인 정보들은 다음과 같다.데이터 소스

날짜 및 시간 System.DateTime.Now컴퓨터 이름 System.Environment.MachineName예외 소스 System.Exception.Source예외 형 Object.GetType, Type.FullName, is, as, typeof 예외 메시지 System.Exception.Message예외 스택 추적 System.Exception.StackTrace호출 스택 System.Environment.StackTrace애플리케이션 도메인 이름 System.AppDomain.FriendlyName어셈블리 이름 System.Reflection.AssemblyName.FullName어셈블리 버전 System.Reflection.AssemblyName.FullName에 포함

쓰레드 ID AppDomain.GetCurrentThreadId쓰레드 사용자 System.Threading.Thread.CurrentPrincipal

3.3.9.5.2. 로그 기록

예외 정보를 활용하기 위해서는 이 정보를 컴퓨터 내에 저장해 두어야 한다. 예외 정보를

저장하는 곳은 다음 중 하나를 선택할 수 있다. Windows 이벤트 로그

사용자 정의 로그 파일

데이터베이스

Windows 이벤트 로그

NT 이상의 운영체제는 시스템 또는 애플리케이션의 에러, 경고, 정보 등을 저장하기 위한 저장

공간을 지원한다. DxFrameworkLite 내에서는 기본적으로 이벤트 로그에 내용을 기록한다.

175


이벤트 로그의 장단점은 다음과 같다.장점

매우 신뢰성이 높은 방법이다. 로그 파일 사이즈를 관리할 수 있다(최대크기, 유지기간, 수동삭제 등) 이벤트 뷰어를 통해 로그를 볼 수 있다. 대부분의 모니터링 도구(Microsoft Operations Manager)들은 이벤트 로그를 사용한다. WMI와 통합이 가능하다. 시스템 관리자들이 이벤트 로그를 다루는데 익숙하다. 여러 애플리케이션이 이벤트 로그에 카테고리별로 나누어서 기록할 수 있다.단점

각 머신이 로컬 이벤트 로그에 기록한다. 즉, 로그를 중앙집중적으로 관리하기 힘들다.참고로, Microsoft Application Center를 사용하면, 여러 서버의 로컬 이벤트 로그를 한곳에

모아서 통합 관리할 수 있게 해준다.

사용자 정의 로그 파일

일반적으로 흔히 사용되며, 이벤트 로그가 성격에 맞지 않을 때 권장된다. DxFrameworkLite 내에서 지원된다.장점

로그 파일 포맷을 마음대로 결정할 수 있다.단점

동시접속을 처리할 수 있는 로그 메커니즘을 작성하기 불편하다. 로그 사이즈를 관리하기 위한 처리 과정을 만들어야 한다. 로그 파일을 보거나 관리하기 위한 툴을 개발해야 한다. 웹 팜 환경에서 로그의 통합 관리가 힘들다.

데이터베이스

로그 파일이 로컬에 저장되는 문제를 해결하기 위해 데이터베이스에 로그 정보를 기록할 수 있다.장점

모든 정보가 중앙집중적으로 저장되며, 원격 머신에서도 접근 가능하다. 데이터베이스 도구를 사용하여 에러 데이터를 조회, 분석, 리포팅이 가능하다. 정보를 구조화하기 편리하다.단점

데이터베이스에 접근하지 못하는 경우(예:네트워크 장애), 로그 정보가 손실된다. 로그 정보를 기록하는데 부하가 걸린다. 데이터를 조회, 관리, 모니터링하기 위한 도구를 개발해야 한다.

176


3.3.10. ASP.NET 상태 정보 관리

3.3.10.1. 개요

웹 폼 페이지와 ASP.NET 페이지 프레임워크는 HTTP를 사용하여 브라우저 또는 클라이언트

장치와 웹 서버 간의 통신을 수행한다. HTTP는 상태 비저장 프로토콜이므로, 일련의 요청이 모두

동일한 클라이언트에서 보낸 것인지의 여부나 심지어는 단일 브라우저 인스턴스에서 페이지나

사이트를 계속 사용 중인지의 여부도 자동으로 알 수 없다. 또한, 페이지는 라운드트립에서

처리될 때마다 소멸되었다가 새로 렌더링되며 Web Forms 페이지의 상태 및 페이지에 포함된

컨트롤의 상태에 관한 정보도 모두 사라진다. 따라서 프로그램에서는 상태정보를 여러 페이지에

걸쳐 유지하기 위한 다양한 기법이 사용되는데, 크게는 클라이언트 기반 상태관리와 서버기반

상태관리 옵션이 있다.ASP.NET에서는 클라이언트 기반 상태관리 방법으로 쿠키(Cookie)와 ViewState를, 서버 기반

상태관리 방법으로 Session, Application, Cache를 제공한다.종류 저장위치 Lifetime 접근제한

Cookie 클라이언트 브라우저 동일 도메인

ViewState 클라이언트 페이지 PostBack 같은 ViewState KeySession 서버 브라우저, 웹 애플리케이션 동일 웹 애플리케이션

Application

서버 웹 애플리케이션 동일 웹 애플리케이션

Cache 서버 웹 애플리케이션 동일 웹 애플리케이션

3.3.10.2. Cookie

쿠키는 클라이언트 파일 시스템의 텍스트 파일에 저장되거나 클라이언트 브라우저 세션의

메모리에 저장되는 소량의 데이터이다. 쿠키에는 서버가 페이지 출력과 함께 클라이언트에

전송하는 페이지 관련 정보가 들어 있다. 쿠키는 일시적(특정 만료 시간과 날짜가 지정된)이거나

영구적일 수 있다.쿠키를 사용하여 특정 클라이언트, 세션 또는 응용 프로그램에 대한 정보를 저장할 수 있다. 쿠키가 클라이언트 장치에 저장되면 브라우저에서 페이지를 요청할 때 요청 정보와 함께 쿠키의

정보가 전달되어 서버에서 쿠키와 해당 값을 읽을 수 있다. 일반적으로는 사용자가 이미 응용

프로그램에서 인증되었음을 나타내는 토큰(대부분 암호화된)을 저장한다.브라우저에서는 쿠키를 처음 만든 서버로 데이터를 다시 보낼 수만 있다. 그러나 악의적인

사용자가 쿠키를 "훔쳐" 그 내용을 읽을 수 있으므로 사용자 이름이나 암호 같은 중요한 정보는

쿠키에 저장하지 않는 것이 좋다. 대신, 서버에서 중요한 정보를 찾는 데 사용할 수 있는 토큰을

저장하는 것이 바람직하다.

177


3.3.10.2.1. 사용법

//C#// 쿠키값을 설정할 때, Response.Cookies[ “key” ].Value = “value”;

//설정된 쿠키값을 가져올 때,string value = Request.Cookies[ “key” ] .Value as string;‘VB.net‘쿠키값을 설정할 때

Response.Cookies(“key”).Value = “value”‘설정된 쿠키값을 가져올 때

Dim value as String = Request.Cookies(“key”).Value

3.3.10.2.2. 고려사항

장점

서버 리소스가 불필요하다. 쿠키는 클라이언트에 저장되며 Post된 후 서버에서 읽는다. 단순하다(단순한 키 값 쌍으로 구성된 용량이 적은 텍스트 기반 구조). 만료 시기를 설정할 수 있다. 브라우저 세션이 종료될 때 만료될 수도 있고 클라이언트의

만료 규칙에 따라 클라이언트 컴퓨터에 무기한 보관될 수도 있다.

단점

크기가 제한되어 있다. 요즘 새로 나오는 브라우저 및 클라이언트 장치 버전에서는

일반적으로 쿠키 크기를 8192바이트까지 지원하지만, 대부분의 브라우저에서는 쿠키 크기를

4096바이트로 제한한다. 사용자가 쿠키를 사용하지 않도록 거부하거나, 클라이언트 장치가 쿠키를 지원하지 않을

수 있다. 보안성이 취약하다. 사용자나 해커가 컴퓨터에서 쿠키를 조작할 수 있기 때문에 보안이

침해되거나 쿠키를 사용하는 응용 프로그램에 오류가 발생할 수 있다. 클라이언트 컴퓨터에서 쿠키의 영속성이 클라이언트 컴퓨터에서의 쿠키 만료 프로세스와

사용자의 의사에 의해 좌우된다.

권장 사용시기

클라이언트에 소량의 정보를 저장해야 하며 보안이 중요하지 않은 경우

178


3.3.10.3. ViewState

웹 폼 페이지 및 웹 폼 컨트롤의 상위 클래스인 Control은 ViewState라는 속성을 통해 동일한

페이지에 대한 여러 요청 사이에 값을 유지하기 위한 사전 개체를 제공한다. 이는 페이지의

라운드 트립 사이에 페이지와 컨트롤 속성 값을 유지하기 위한 방법이다.페이지를 처리할 때 현재 페이지와 컨트롤 상태는 문자열로 해싱되어 Hidden 필드로 페이지에

저장된다. 페이지를 다시 서버에 Post할 때 페이지 초기화 시 ViewState 문자열을 파싱해서

페이지 속성 정보를 복원한다. 컨트롤 상태 외에도 임의의 사용자 데이터도 ViewState에 저장할

수 있다.

3.3.10.3.1. 사용법

//C#// ViewState 값을 설정할 때,ViewState[ “key” ] = “value”;

// 설정된 ViewState 값을 가져올 때,string value = ViewState[ “key” ] as string;

‘VB.net‘ViewState 값을 설정할 때,ViewState(“key”) = “value”

// 설정된 ViewState 값을 가져올 때,Dim value as String = ViewState(“key”).ToString()

3.3.10.3.2. 고려사항

장점

서버 리소스가 불필요하다. ViewState는 페이지 코드 내의 구조에 포함된다. 구현이 용이하다. ASP.NET 웹 폼의 경우 페이지 및 컨트롤 상태가 자동으로 보존된다. 보안성이 보다 뛰어나다. ViewState 값은 유니코드 구현을 위해 해시, 압축 및

인코딩된다.

단점

ViewState를 많이 사용할수록 성능이 저하된다. ViewState는 페이지 내에 저장되므로,

179


큰 값을 저장하면 페이지 로딩 시 속도가 느려진다. 또한 ViewState 값을 암호화, 파싱하는데도

시간이 소요된다. 데이터가 해시된 상태로 저장되지만 역시 훼손이 가능하므로 보안 문제가 발생할 수 있다.

권장 사용시기

동일 페이지의 라운드 트립(PostBack) 간에 소량의 정보를 저장해야 하는 경우

참고

웹 폼 컨트롤 중에서 EnableViewState 속성이 True로 설정된 컨트롤만 자동으로

ViewState를 통해 상태 정보를 유지한다.상태를 유지할 필요가 없는 컨트롤들은 EnableViewState를 False로 설정하여

ViewState 크기를 줄이면 성능이 향상된다.

3.3.10.4. Application

ASP.NET을 사용하면 HttpApplicationState 클래스의 인스턴스인 Application을 사용하여 각

활성 웹 응용 프로그램에 대한 값을 저장할 수 있다. 응용 프로그램 상태는 웹 응용 프로그램의

모든 페이지에서 액세스할 수 있는 전역 저장 메커니즘이므로 서버 라운드트립 간에 그리고

페이지 간에 유지되어야 할 정보를 저장하는 데 유용하다.

3.3.10.4.1. 사용법

//C#// Application 값을 설정할 때,Application.Lock();Application[ “key” ] = “value”;Application.Unlock();

// 설정된 Application 값을 가져올 때,string value = Application[ “key” ] as string;

‘VB.net‘Application 값을 설정할 때,Application.Lock()Application(“key”) = “value”Application.Unlock()

‘설정된 Application 값을 가져올 때,

180


Dim value as string = Application(“key”).ToString()

3.3.10.4.2. 고려사항

장점

구현이 용이하다. 기존의 ASP 개발자에게도 친숙하며, ASP와도 호환된다. 전역적인 범위를 가진다. 웹 애플리케이션 내의 모든 페이지에서 접근할 수 있으므로, 데이터를 공유할 수 있다.

단점

웹 애플리케이션이 실행되고 있는 특정 프로세스에 대해서만 전역적인 특성을 가지므로, 웹 가든 및 웹 팜 구성에서 Application을 공유할 수 없다.

영속적이지 않다. 서버의 실행이 중지되거나, 서버 업그레이드, 종료 시 Application 데이터가 포함된 웹 서버 프로세스가 파괴되면 데이터가 손실된다.

서버의 리소소를 요구한다. 즉 웹 애플리케이션의 확장성이나 서버의 상태 및 성능에

영향을 줄 수 있다. 다중 스레드 서버 환경 내에서 동시성 및 동기화 관련 문제가 발생하므로, Lock 및

Unlock을 통해 동기화 코딩을 해야 한다.

권장 사용시기

자주 변경되지 않고 많은 사용자가 이용하는 전역적인 정보를 저장해야 하며 보안이

중요하지 않은 경우에 사용한다.응용 프로그램 상태에는 많은 양의 정보를 저장하지 않는 것이 좋다.

3.3.10.5. Session

세션이란 어떤 기간 동안에 하나의 클라이언트와 웹 서버 사이에 발생하는 일련의 관련된

트랜잭션으로 정의할 수 있다. 각 세션에는 SessionID가 할당되며, 세션 정보는 키-값 구조로

저장되어 서버 라운드 트립 및 페이지 요청 간에 유지될 수 있다. ASP.NET을 사용하면

HttpSessionState 클래스의 인스턴스인 Session를 사용하여 각 활성 웹 응용 프로그램 세션에

대한 값을 저장할 수 있다.세션 상태를 사용하면 다음을 할 수 있다.

브라우저 또는 클라이언트 장치 요청을 고유하게 식별하고 이 요청을 서버의 개별 세션

인스턴스로 매핑할 수 있다. 동일한 세션 내의 여러 브라우저 또는 클라이언트 장치 요청에 사용하기 위해 서버에 세션

관련 데이터를 저장할 수 있다. 적절한 세션 관리 이벤트를 발생시킬 수 있다. 또한 이들 이벤트를 활용하는 응용

181


프로그램 코드를 작성할 수도 있다.3.3.10.5.1. 사용법

//C#// Session 값을 설정할 때,Session[ “key” ] = “value”;

// 설정된 Session 값을 가져올 때,string value = Session[ “key” ] as string;

‘VB.net‘Session 값을 설정할 때,Session.Item(“key”) = “value”

‘설정된 Session 값을 가져올 때,Dim value as String = CStr(Session.Item(“key”))

3.3.10.5.2. 고려사항

장점

구현이 용이하다. 기존의 ASP 개발자에게도 친숙하며, ASP와도 호환된다. 세션 고유의 이벤트(Session_Start, Session_End)를 처리할 수 있다. 세션 전용 프로세스나 SQL 서버로 저장하여 IIS 또는 ASP.NET Worker Process의

실행이 중지되는 경우에도 손실되지 않게 할 수 있다. 다중 컴퓨터(웹 팜) 및 다중 프로세스 구성(웹 가든)에서 모두 사용할 수 있도록 확장성을

가진다. 쿠키를 지원하지 않는 브라우저에서도 동작할 수 있다.

단점

서버의 리소소를 요구한다. Session 변수는 삭제될 때까지 메모리에 남아 있으므로

서버의 성능이 저하된다.

권장 사용시기

개별 세션에 따라 달라지는 수명이 짧은 정보를 저장해야 하며 보안이 중요하지 않은

경우에 사용한다.세션 상태에는 많은 양의 정보를 저장하지 않는 것이 좋다. 세션 상태 개체가 만들어지고

응용 프로그램의 모든 세션이 존속하는 동안 유지된다. 많은 사용자에게 서비스를

182


제공하는 응용 프로그램의 경우에는 서버 리소스를 많이 사용하므로 확장성이 떨어질 수

있다.

세션 식별

각각의 활성 ASP.NET 세션은 URL에서 허용되는 ASCII 문자만 포함된 120비트 SessionID를

사용하여 식별되고 추적된다. SessionID 값은 세션들이 충돌하지 않도록 하는 고유성과

악의적인 사용자가 새로운 SessionID를 사용하여 기존 세션의 SessionID를 계산할 수 없도록

하는 무작위성을 보장하는 알고리즘을 사용하여 생성된다.SessionID는 web.config의 구성에 따라 HTTP 쿠키 또는 SessionID 문자열을 URL에 추가하여

(Cookie-less Session)을 통해 전달된다. 기본값은 쿠키이며, 사용자가 쿠키를 사용하지 않도록

거부했거나 쿠키를 지원하지 않는 클라이언트 장치에서는 web.config에서 <sessionState cookieless="true">로 설정한다.

세션 상태 저장

ASP.NET은 세션의 상태를 저장하는 위치를 InProcess, Out-Of-Process, SQL Server로 지정할

수 있다. 기본 모드는 InProcess이며, 웹 팜 또는 웹 가든 상태에서는 Out-Of-Process나 SQL Server 모드를 사용해야 한다. 세션 상태 모드의 변경은 web.config 파일의 <sessionState> 요소의 mode 특성을 InProc/StateServer/SQLServer로 설정하면 된다. StateServer로 한

경우에는 stateConnectionString을, SQLServer로 한 경우에는 sqlConnectionString을

추가로 설정해야 한다.

3.3.10.6. Cache

ASP.NET은 대량 서버 리소스를 만들어야 하는 개체를 메모리에 저장하는데 사용할 수 있는

강력하고 사용하기 쉬운 캐싱 메커니즘을 제공한다. Cache는 웹 애플리케이션에 따라

만들어지며, 애플리케이션의 수명과 관련이 있다.Cache는 키-값 쌍의 자료구조이며, 설정 시간 이후 캐시가 만료되도록 정책을 설정할 수 있다. 또한 외부 파일, 디렉터리 또는 다른 캐싱된 항목을 기준으로 캐싱된 항목의 유효성을 정의할 수

있다. 이러한 종속성을 추적하여 만료 정책을 설정할 수도 있다.

3.3.10.6.1. 사용법

//C#// Cache 값을 설정할 때,Cache[ “key” ] = “value”;Cache.Insert("key", "value", new CacheDependency(Server.MapPath(\\myServer\myConfig.xml))); // 파일 종속성

추가

183


Cache.Insert("key", "value", null, DateTime.Now.AddMinutes(2), NoSlidingExpiration); // 절대 만료(2분) 정책 추가

Cache.Insert("key", "value", null, NoAbsoluteExpiration, TimeSpan.FromSeconds(30)); // 슬라이딩 만료(30초) 추가

// 설정된 Cache 값을 가져올 때,string value = Cache[ “key” ] as string;

‘VB.net‘Cache 값을 설정할 때,Cache.Item(“key”) = “value”Cache.Insert("key", "value", _ new CacheDependency(Server.MapPath(\\myServer\myConfig.xml))) ‘ 파일 종속성

추가

Cache.Insert("key", "value", Nothing, DateTime.Now.AddMinutes(2), NoSlidingExpiration); ‘ 절대 만료(2분) 정책 추가

Cache.Insert("key", "value", Nothing, NoAbsoluteExpiration, TimeSpan.FromSeconds(30)) ‘슬라이딩 만료(30초) 추가

‘설정된 Cache 값을 가져올 때,Dim value as String = CType(Cache.Item(“key”),String)

3.3.10.6.2. 고려사항

장점

구현이 용이하다. 전역적인 범위를 가진다. 웹 애플리케이션 내의 모든 페이지에서 접근할 수 있으므로, 데이터를 공유할 수 있다.

Application과는 달리 다중 쓰레드에 안전하므로 동기화 코딩을 할 필요가 없다. Cache 만료 정책을 다양하게 설정할 수 있다.

단점

웹 애플리케이션이 실행되고 있는 특정 프로세스에 대해서만 전역적인 특성을 가지므로, 웹 가든 및 웹 팜 구성에서 공유할 수 없다.

영속적이지 않다. 서버의 실행이 중지되거나, 서버 업그레이드, 종료 시 Cache 데이터가

포함된 웹 서버 프로세스가 파괴되면 데이터가 손실된다. 서버의 리소소를 요구한다. 즉 웹 애플리케이션의 확장성이나 서버의 상태 및 성능에

184


영향을 줄 수 있다.

권장 사용시기

웹 애플리케이션 내에서 공유해야 하는 데이터를 사용해야 하는 경우

Application 변수 대신에 Cache를 사용하는 것을 권장

종속성, 시간 만료 등을 통해 데이터를 삭제, 갱신해야 하는 경우

특정 주기가 지나야 변동되는 데이터 등을 캐싱하여 웹 애플리케이션의 성능을 향상해야

할 필요가 있는 경우

3.3.11. 구성 정보 파일 처리

.NET에서는 XML 형식의 구성 정보 파일(Configuration File)를 통해 컴퓨터나 애플리케이션이

필요로 하는 설정 정보를 사용할 수 있다. 구성 정보 파일에는 여러가지 유형이 있지만, 여기서는

그 중에서 애플리케이션 구성 정보 파일을 다루는 방법 위주로 설명하도록 하겠다.

3.3.11.1. 구성 파일의 유형3.3.11.1.1. 컴퓨터 구성 파일

컴퓨터 구성 파일인 Machine.config에는 전체 컴퓨터에 적용되는 설정이 포함되어 있다. Machine.config 구성파일은 컴퓨터 전반의 어셈블리 바인딩, 내장 원격 채널 및 ASP.NET의

구성정보를 가지고 있다. 이 구성파일의 위치는 %runtime install path%\Config 디렉터리에

위치한다. 예를 들어, Windows XP 운영체제에 .NET Framework 1.1이 설치되어 있다면 C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\에 Machine.config이 위치한다.이 구성파일에 대한 보다 구체적인 내용은 .NET Framework SDK 또는 Visual Studio .NET에

포함된 도움말을 참조하기 바란다.대신 알아둘 점은 Machine.config 파일에도 응용 프로그램의 구성정보를 지정할 수 있다는

것이다. System.Configuration 네임스페이스의 구성정보관련 클래스인

ConfigurationSettings 또는 AppSettingsReader 클래스를 사용해서 구성정보를 읽을 경우

응용 프로그램 구성파일보다 먼저 Machine.config 파일을 먼저 검색하기 때문에 여러 응용

프로그램의 공통적인 구성정보를 지정할 경우에 Machine.config 파일을 사용하는 것이 가장

효율적인 방법이 되는 경우가 많다.

3.3.11.1.2. 보안 구성 파일

보안 구성 파일에는 코드 그룹 계층 구조 및 정책 수준과 관련된 사용 권한 집합에 대한 정보가

포함되어 있다. 보안 구성 파일이 손상되지 않도록 이 파일을 직접 수정하기 보다는 .NET Framework 구성 도구(Mscorcfg.msc) 또는 코드 액세스 보안 정책 도구(Caspol.exe)를

사용하여 보안 정책을 수정할 것을 권장한다. 보안 구성파일은 이 단원에서 다루고자 하는 내용이

185


아니기 때문에 보다 구체적인 내용은 .NET Framework SDK 또는 Visual Studio .NET에 포함된

도움말을 참조하기 바란다.

3.3.11.1.3. 애플리케이션 구성 파일

애플리케이션 구성 파일은 특정 애플리케이션의 설정을 담은 것으로, 이 파일에는

애플리케이션에서 실행 시 참조하는 애플리케이션 전용 구성 설정과 어셈블리 바인딩 정책, 원격

개체 등과 같은 공용 언어 런타임에 읽을 구성 설정이 포함되어 있다.애플리케이션 구성 파일의 이름과 위치는 애플리케이션의 호스트에 따라 달라지는데 호스트는

다음 중 하나가 될 수 있다.

실행 파일에서 호스팅되는 응용 프로그램

실행 파일에 의해 호스팅되는 응용 프로그램의 구성 파일은 응용 프로그램과 같은 디렉터리에

위치한다. 구성 파일의 이름은 응용 프로그램의 이름과 같으며 .config 확장명을 갖는다. 예를

들어, myApp.exe라는 응용 프로그램은 myApp.exe.config라는 구성 파일에 연결될 수 있다.

ASP.NET에서 호스팅되는 응용 프로그램

ASP.NET 구성 파일은 Web.config라고 부르며, ASP.NET 애플리케이션에 있는 구성 파일은 URL 경로에 있는 구성 파일 설정을 상속합니다. 예를 들어, URL www.microsoft.com/aaa/bbb에서

www.microsoft.com/aaa가 웹 애플리케이션인 경우 이 애플리케이션에 연결되는 구성 파일은

www.microsoft.com/aaa에 위치합니다. 하위 디렉터리인 /bbb에 있는 ASP.NET 페이지는 응용

프로그램 수준의 구성 파일에 있는 설정과 /bbb에 있는 구성 파일의 설정을 모두 사용한다.

Internet Explorer에서 호스팅되는 응용 프로그램

Internet Explorer에서 호스팅되는 응용 프로그램이 구성 파일을 가지면 이 파일의 위치는 다음

구문을 사용하여 <link> 태그에 지정된다.

<link rel="ConfigurationFileName" href="location">이 태그에서 location은 구성 파일의 URL 로서, 응용 프로그램 기본 디렉터리를 설정한다. 구성

파일은 응용 프로그램의 웹 사이트와 같은 곳에 위치해야 한다.환경 설정 파일의 확장자가 *.config 로 되어 있는 경우, ASP.NET은 해당 확장자를

ForbiddenHandler로 지정해 두고 있다. 그렇기 때문에, 해당 Handler를 변경해 주지 않으면, 환경 설정파일을 사용할 수 없다.이를 해제 하기 위하여, 통상 아래와 같이 Internet Explorer에서 호출하는 웹 어플리케이션의

web.config 에 설정해 준다.

<system.web> <httpHandlers> <remove verb="*" path="*.config" /> <add verb="*" path="web.config"

186


type="System.Web.HttpForbiddenHandler" /> </httpHandlers></system.web>

3.3.11.2. 기본 구성 정보 섹션 사용법

.NET Framework에서는 기본적으로 <appSettings>라는 미리 정의된 구성 섹션을 제공한다. 이 구성 섹션 내에는 다음과 같이 키(key)-값(value) 쌍을 선언하여 애플리케이션의 구성 정보를

설정할 수 있다.

<configuration>  <appSettings> <add key="Application Name" value="MyApplication" /> </appSettings></configuration>위에서는 ApplicationName이라는 키에 “MyApplication”이라는 구성 정보 값을 지정하고 있다. 이제 애플리케이션에서는 다음과 같은 코드를 통해 ApplicationName 키로 이 구성 정보를

액세스 할 수 있다.

//C#public void ReadMyAppSettings(){ string appName = ConfigurationSettings.AppSettings["Application Name"];

Console.WriteLine(); Console.WriteLine("Reading AppSettings"); Console.WriteLine("Application Name: " + appName);}

‘VB.netPublic Sub ReadMyAppSettings() Dim appName As String = ConfigurationSettings.AppSettings("Application Name") Console.WriteLine() Console.WriteLine("Reading AppSettings") Console.WriteLine(("Application Name: " + appName))End Sub

187


ConfigurationSettings.AppSettings 라는 클래스로 <appSettings> 구성 섹션의 설정값에

액세스하는 방식은 애플리케이션의 구성정보가 많지 않을 경우에는 괜찮은 방식이지만 어느 정도

규모가 되는 애플리케이션에서는 단순히 키-값 쌍 형식의 설정만 할수 있는 <appSettings> 구성 섹션만으로는 곧 한계에 부딪치게 된다. 그러므로, 필요한 구성정보가 다소 복잡해지면, 계층적 구조 또는 카테고리화가 가능한 구성정보가 필요하게 된다.

3.3.11.3. 사용자 지정 섹션 사용법

기본 <appSettings> 섹션이 불충분하다면, 임의로 사용자 지정 섹션을 선언할 수 있다. 다음은

DxFrameworkLite 에서 사용하는 구성 정보 파일의 예이다.

<?xml version="1.0" encoding="utf-8" ?><configuration>

<configSections> <section name="DxFrameworkLite" type="DxFrameworkLite.Configuration.AppSettingsReader, DxFrameworkLite.Configuration"/> <section name="DxApplication" type="DxFrameworkLite.Configuration.AppSettingsReader, DxFrameworkLite.Configuration"/> </configSections> <DxFrameworkLite> <AppSettingsReader> <add key="RaiseException" value="true" /> </AppSettingsReader> <SqlDbAgent><add key="ConnectionString" value="data source=(local);initial catalog=EIMSDB;integrated security=SSPI; "/> <add key="CommandTimeout" value="30" /> </SqlDbAgent> <ConnectionStrings>

<add key="OracleDBConnectionSample" value="Data Source=;User ID=;Password=;Pooling=false" /> <add key="AnotherDBConnectionString" value="server=(local);database=Northwind;uid=;pwd=;"/> </ConnectionStrings>

188


</DxFrameworkLite> <DxApplication> <ExeTimeLog> <add key="LogFileName" value="ExeTimeLog.txt"/> <add key="TraceEnable" value="true"/> <add key="Enable" value="true"/> </ExeTimeLog> <CustomError> <add key="Mode" value="RemoteOnly"/> <add key="TransferForm" value="Common/Forms/DisplayError.aspx"/> </CustomError></DxApplication>…

3.3.11.3.1. <configSections> 섹션

여기에는 사용자 지정 섹션을 선언한다. name의 경우 사용자 지정 섹션 이름을, type에는

사용자 지정 섹션 핸들러의 type을 지정한다.위의 예제에서는 DxFrameworkLite과 DxApplication이라는 2개의 사용자 지정 섹션을

정의하고 있으며, 섹션 핸들러로 DxFrameworkLite.Configuration.AppSettingsReader를

지정하고 있다.

3.3.11.3.2. <DxFrameworkLite> 섹션

DxFrameworkLite의 동작을 지정하는 섹션으로, 사전에 정의된 키-값 쌍으로 구성되어 있다.하위 섹션 키 값 설명

AppSettingsReader

RaiseException 구성 파일에서 지정된 키 값을 찾지 못했을 때, 예외를 발생시킬지 여부를 결정한다. 기본값은 true이며 false로 설정되면, 예외가 발생하지 않고 null 값이 반환된다.

SqlDbAgent ConnectionString SqlDbAgent에서 사용하는 DB 연결 문자열로, SqlDbAgent는 모든 동작 시에 이 연결 문자열을

디폴트로 사용합니다.CommandTimeout

SqlDbAgent가 실행하는 명령의 제한시간이다. 기본값은 30초이며, 지정시간이 경과하면 명령을

취소하고 예외를 발생시킨다.

189


OracleDbAgent SqlDbAgent와 동일

OleDbAgent SqlDbAgent와 동일

3.3.11.3.3. DxApplication 섹션

여기에는 개발하고 있는 애플리케이션에서 사용할 구성 정보 값들을 임의로 넣으면 된다. 위의

예에서는 <ExeTimeLog>와 <CustomError>라는 섹션을 정의해서 사용하고 있다. 애플리케이션에서 구성 정보 값을 읽으려면 다음과 같이 하면 된다.

//C#using DxFrameworkLite.Diagnostics;…AppSettingsReader reader = new AppSettigsReader("DxApplication/ExeTimeLog");string str = reader["LogFileName"];

‘VB.netImports DxFrameworkLite.Diagnostics…Dim reader = New AppSettigsReader("DxApplication/ExeTimeLog") 'Dim str As String = reader("LogFileName")

3.3.12. 애플리케이션 보안 – 인증 및 권한 부여

3.3.12.1. 인증

인증(Authentication)은 애플리케이션에 접근하는 사용자의 신원(Identity)를 확인하는 과정을

의미한다. 불특정 다수에 의해 접근되는 애플리케이션이 아니라면, 인증 과정은 필수적으로

요구된다.

3.3.12.1.1. ASP.NET 인증

ASP.NET은 Windows 인증/폼 인증/Passport 인증의 세가지 인증 공급자를 제공한다.

Windows 인증

IIS의 인증 모델을 그대로 사용하는 것으로, 기본 인증(Basic Authentication) / 다이제스트 인증

(Digest Authentication) / Windows 통합 인증(Integrated Authentication)의 세가지 방법이

있다.

폼 인증

폼 인증(Form Authentication)은 일반적인 웹 사이트에서 즐겨 사용되는 방법으로 ID와

190


패스워드를 물어보는 인증 폼을 제공한 후, 인증된 사용자에게는 인증 토큰을 발급하게 된다.폼 인증 사용 시에는 System.Web.Security.FormAuthentication 클래스의 메서드들을

활용하여 작업하게 된다. 자세한 내용은 MSDN에서 FormAuthentication 클래스 설명을

참조한다.

패스포트 인증

패스포트 인증(Passport Authentication)은 Microsoft의 SSO 시스템인 Passport 서비스를

통해 인증을 하는 것을 말한다. 자세한 내용은 Passport 관련 사이트

(http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp)를

참조하도록 한다.

인증 공급자를 사용하려면, web.config에서 변경하면 된다. 다음은 폼 인증의 예이다.

<authentication mode="Forms"><forms name=".ASPXAUTH" protection="All" timeout="60" />

</authentication>

.NET에서는 IPrincipal.Identity를 사용하여 보안 컨텍스트의 현재 사용자에 관한 정보에 접근할

수 있다. ASP.NET에서는 HttpContext.Current.User.Identity를 통해 접근할 수 있다. 다음은

ASP.NET에서 사용하는 예이다.

//C#if (HttpContext.Current.User.Identity.IsAuthenticated()) { // 인증 여부 파악

… string userName = HttpContext.Current.User.Identity.Name; // 사용자 이름을 가져옴

}

‘VB.netIf HttpContext.Current.User.Identity.IsAuthenticated() Then ' 인증 여부 파악

… Dim userName As String = HttpContext.Current.User.Identity.Name ' 사용자 이름을

가져옴

End If

3.3.12.2. 권한 부여

권한 부여(Authorization)은 어떤 사용자가 지정된 리소스에 액세스 할 수 있는 권한이 있는지를

관리하는 것을 의미한다.

191

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp


3.3.12.2.1. 사용자 지정 권한 부여

통상적으로 시스템 내에 사용자와 사용자가 접근할 수 있는 리소스(URL, 페이지 등)가 어떠한

것인지를 정의하는 권한 테이블을 두게 된다. 권한을 가지지 못한 사용자에게는 메뉴나 화면

자체를 보여주지 않는 경우가 많으므로, Presentation 계층에서 권한 점검을 하는 경우가 많다. 이러한 권한 점검은 Windows Form이나 웹 폼의 부모 클래스에서 처리하도록 하면, 매 화면마다

권한 처리 코드를 작성하는 것을 피할 수 있다.사용자 지정 권한 부여는 시스템마다 다르므로, 각자의 상황에 따라서 구현하기 바란다.

3.3.12.2.2. 역할 기반 보안

역할 기반 보안(Role-based Security)은 주로 COM+에서 사용되는 기술로 사용자들을 여러

개의 역할로 그룹을 지은 다음, 해당 역할에 따라 특정 리소스에 접근하는 권한을 제어하는

것이다. 예를 들어, COM+ 컴포넌트의 특정 클래스나 메서드의 경우에는 관리자만이 접근할 수

있도록 역할을 부여하는 것이다.역할 기반 보안에 대한 자세한 설명은 MSDN을 참조하기 바란다.

3.3.12.2.3. ASP.NET 권한 부여

ASP.NET에서는 권한 부여를 처리하기 위한 기본적인 메커니즘을 제공한다.

파일 권한 부여

파일 권한 부여는 FileAuthorizationModule에서 수행하며 Windows 인증을 사용할 때

활성화된다. 또한 .aspx 또는 .asmx 처리기 파일의 ACL(액세스 제어 목록) 검사를 통해

사용자에게 액세스 권한이 있는지 여부를 확인한다.

URL 권한 부여

URL 권한 부여는 사용자와 역할을 URL 네임스페이스에 매핑하는 URLAuthorizationModule에서 수행한다. 이 모듈은 긍정적 및 부정적 권한 부여 모두를 구현한다. 즉, 이 모듈을 사용하면

특정 집합, 사용자 또는 역할에 대한 임의의 일부 URL 네임스페이스에 선택적으로 액세스를

허용하거나 거부할 수 있다.URL 권한 부여를 사용하려면, 애플리케이션의 루트 디렉터리 또는 하위 디렉터리에

<authorization> 섹션을 갖는 web.config 파일을 정의하면 된다. 다음은 그 예이다.

<authorization> <allow users="Kim"/>  <allow roles="Admins"/>  <deny users="John"/>  <deny users="?"/> 

192


</authorization>기타 옵션들에 대해서는 MSDN에서 ‘ASP.NET 권한 부여’를 참조한다.

3.4. 테스트

애플리케이션 구현이 완료되면, 요구사항을 제대로 만족하도록 점검해보기 위해서

애플리케이션을 테스트하는 과정이 필수적이다. 애플리케이션 테스트는 필요한 기능이 제대로

동작하는지를 점검하기 위한 기능 테스트(Functional Test)와 시스템이 어느 정도의 사용자를

감당할 수 있는지를 점검해보기 위한 성능 및 부하 테스트(Performance / Load Test)로

나누어진다.

3.4.1. 기능 테스트

3.4.1.1. 개요

통상적으로 기능 테스트는 Use Case 시나리오를 바탕으로 애플리케이션의 정상 동작 유무를

찾아보게 된다. 정상적인 시나리오뿐만 아니라 사용자가 실수로 비정상적인 값을 입력했을 때와

같은 예외적인 상황에 대해서도 제대로 처리가 되었는지를 파악해야 한다.

3.4.1.2. 단위 테스트

CBD 기반의 개발 방법론으로 작성되었을 때는 작성된 비즈니스 로직 컴포넌트가 제대로

동작하는지를 점검해보기 위해 단위 테스트(Unit Test)를 수행하는 것이 필수적이다. 그러나, 대량의 작업인 경우 모든 경우의 수를 사람이 수동으로 일일이 테스트 해보는 것은 쉬운 일이

아니며, 시간과 노력이 낭비되게 된다.단위 테스트를 수행하는 방법은 여러가지가 있지만, 단위 테스트 도구를 활용하는 것이 좋다. 이러한 단위 테스트 도구에는 NUnit이 있다.

3.4.1.2.1. NUnit 소개

NUnit은 Kent Back의 Test-First Development 이론을 기반으로 만들어졌으며, JUnit을 .NET Framework에 맞게 포팅된 단위 테스트 도구이다.NUnit에 관한 정보나 다운로드를 받으려면 다음 사이트를 참고하도록 한다.

http://www.nunit.org

3.4.1.2.2. 테스트 코드 작성

다음과 같은 클래스를 작성했다고 가정하자.

193

http://www.nunit.org/


namespace bank{

public class Account{

private float balance;public void Deposit(float amount){

balance+=amount;}

public void Withdraw(float amount){

balance-=amount;}public void TransferFunds(Account destination, float amount){}

public float Balance{

get{ return balance;}}

}}이 클래스를 테스트하기 위한 코드를 다음과 같이 작성한다.

namespace bank{

using NUnit.Framework;

[TestFixture]public class AccountTest{

[Test]public void TransferFunds(){

Account source = new Account();

194


source.Deposit(200.00F);Account destination = new Account();destination.Deposit(150.00F);

source.TransferFunds(destination, 100.00F);Assert.AreEqual(250.00F, destination.Balance);Assert.AreEqual(100.00F, source.Balance);

}}

}테스트를 위한 클래스에 TestFixture, 메서드에 Test라는 특성이 적용된 것을 알 수 있다. 추가적인 특성이나 테스트 코드 작성에 대해서는 NUnit 관련 문서를 참조하도록 한다.

3.4.1.2.3. 테스트 수행

테스트를 수행하기 위해서는 NUnit에서 제공하는 도구를 통해 테스트 코드가 포함된 어셈블리를

실행하면 된다. NUnit에서는 커맨드라인 및 GUI 테스트 도구를 제공하고 있다.

nunit-console.exe (커맨드 라인 테스트 도구)

테스트를 수행한 후 결과를 XML 파일로 저장한다.

[그림 59] NUnit 커맨드라인 툴

nunit-gui.exe (GUI 테스트 도구)

GUI를 갖춘 테스트 도구로 테스트 성공 여부를 시각적으로 보여준다.

195


[그림 60] NUnit GUI 툴

3.4.1.3. 사용자 액션 테스트

단위 테스트가 완료되면, UI와 함께 각 기능들이 제대로 동작하는지를 사용자의 관점에서

점검해봐야 한다. Use Case 시나리오를 바탕으로 테스트 시나리오를 작성한 후, 항목을 점검해

나가도록 한다.

3.4.2. 성능 및 부하 테스트

3.4.2.1. 개요

개발이 완료된 애플리케이션의 가용성을 확인해 보기 위해서는 시스템에 부하를 주고 전반적인

성능을 테스트해 봐야 한다.특정 수치의 부하를 줬을 때 애플리케이션 서버 CPU 사용율, 데이터베이스 서버 CPU 사용율, Bottleneck, 동시사용자수에 따른 초당 응답시간(또는 페이지) 비교 등을 통해, 시스템의 적정

하드웨어 자원을 산정하고, 최적의 플랫폼 환경을 추출한다.이러한 테스트는 C/S 애플리케이션의 경우, 전체 사용자 수를 예측할 수 있으므로 비교적 쉽고

원활하게 테스트가 가능하다. 그러나, 불특정 다수를 대상으로 하며 특정 시간대에 사용자가 몰릴

수 있는 웹 애플리케이션의 경우에는 수동 테스트가 불가능하므로 부하 테스트 도구를 사용해서

테스트를 하는 경우가 많다.여기에서는 Visual Studio .NET에 포함된 ACT(Application Center Test)를 사용하여 테스트를

수행하는 방법에 대해서 설명하도록 하겠다.

196


3.4.2.2. ACT를 사용한 테스트3.4.2.2.1. ACT 실행

<시작->모든 프로그램->Visual Studio .NET->Visual Studio .NET Enterprise 기능>을

선택하고 <Microsoft Application Center Test>을 선택한다.

3.4.2.2.2. 테스트 프로젝트 생성

<파일->새 프로젝트>을 선택한다. 프로젝트 이름과 위치를 선택한다.

[그림 61] ACT

3.4.2.2.3. 사용자 생성

여러 명의 사용자 계정에 따라서 테스트를 해볼 필요가 있는 경우, 사용자를 추가해야 한다. 사용자

추가 시에는 수동으로 입력하거나 .csv 파일로부터 가져오는 방법이 있다. .csv를 쓰는 경우에는

ID와 암호로 구분되어 있어야 한다.사용자 그룹을 생성한 후, 사용자 그룹에 대한 “사용자 가져오기”을 실행, 위에서 생성한 사용자

정보(*.csv)를 가져온다. ACT의 “사용자”를 마우스 오른쪽 버튼으로 클릭한 후, <추가>을 클릭한다. 생성된 “새 사용자 그룹”을 마우스 오른쪽 버튼으로 선택한 후, “이름 바꾸기”를 선택, 사용자 그룹 이름을 변경한다.

생성한 “사용자 그룹”을 클릭한 후, <작업->사용자 가져오기>를 선택한다. 생성한 *.csv 파일을 선택한다.

197


[그림 62] 사용자 가져오기

생성된 사용자 정보 중 필요없는 데이터를 삭제한다. (예: 컬럼 명)

[그림 63] 사용자를 생성한 예

3.4.2.2.4. 테스트 생성

대상 웹 어플리케이션 프로젝트에 대한 테스트 시나리오를 생성한다. ACT의 <테스트>를 마우스 오른쪽 버튼으로 클릭한 후, “새 테스트”를 실행하여, “새

테스트 마법사”를 실행한다. <테스트 원본>에서 <새 테스트 기록하기>를 선택한다. <테스트 종류>에서 “VBScript (*.vb)”를 선택한다. <브라우저 기록>에서 “기록 시작” 버튼을 클릭한다.

198


[그림 64] 새 테스트 마법사

자동적으로 생성된 웹 브라우저에서 테스팅 시나리오대로 작업을 진행한다. 인증 화면에서는 알고 있는 “사용자 ID”와 “패스워드”를 입력하고 진행한다. 시나리오에 따른 작업이 완료되면, <브라우저 기록> 창에서 “기록 중지” 버튼을 클릭한다. 생성된 프로젝트를 마우스 오른쪽 버튼으로 클릭한 후, <속성>을 클릭한다.

[그림 65] 생성된 테스트

일반 탭에서 “브라우저 동시 연결 수”는 테스트 리퀘스트를 할 클라이언트 인스턴스 수를

의미한다. “브라우저 동시 연결 수”을 설정한다. 서서히 “연결 수”를 늘려가면서, 사용자 수에 따른

시스템 동작을 분석할 수 있다.

199


테스트 지속 시간을 설정한다. 사용자 설정 탭에서, 생성한 사용자 그룹을 선택한다. 카운터 탭에서 윈도우 Performance Counter에 대한 추가 모니터링을 지정한다. SQL Server에 대한 시스템 리소스 사용량을 모니터링 할 수 있다.3.4.2.2.5. 테스트 스크립트 사용자 정의

테스트 마법사를 활용한, 테스트 시나리오의 경우, 웹어플리케이션 테스트에 필요한 세밀한

설정을 할 수 없다.예를들면, 시나리오 작성시에는 특정 사용자의 ID와 패스워드를 사용하지만, 실제 테스트시에는

생성한 사용자 그룹의 사용자 정보를 무작위로 활용, 테스트 할 수 있어야 한다. 기본적으로

생성된 “테스트”를 클릭하면, 실행할 스크립트 코드가 나타난다.스크립트 코드에 대한 자세한 사항은 마이크로소프트 Application Center Test 의 도움말

기능을 참조한다. 나타난 스크립트 코드 중 “로그인” 페이지를 ACT의 <편집->찿기>로 찾는다.(찾기 예 : index.aspx)

찾은 프로그램 모듈 중 웹페이지의 컨트롤 명에 해당하는 값을 User 객체를 사용하여

설정한다.(예:EMPNO=0->EMPNO=User.Name, EMPDEPCODE=TFAA->EMPDEPCODE=User.Password)

200


3.4.2.2.6. 테스트 실행

생성한 테스트를 마우스 오른쪽 버튼으로 클릭한 후, “테스트 시작”을 선택한다. 다음

화면과 같이 테스트가 실행된다.

[그림 66] 실행 중인 테스트

테스트 진행 시간을 너무 길게 설정한 경우, 테스트 중에 <테스트 중지> 버튼을

클릭해서, 중지시킬 수 있다.3.4.2.2.7. 결과 분석

ACT 의 <결과> 항목을 선택하면, 실시한 테스트 결과가 테스트 시나리오에 따라

분류되어 나타난다.

[그림 67] 테스트 결과 항목

201


분석하고자 하는 두가지 이상의 테스트 결과 체크박스를 체크하면, 테스트 시나리오 간

요약정보 및 그래프와 함께 다양한 요약정보를 비교할 수 있다.

[그림 68] 테스트 결과 요약 정보

드롭다운 박스에서 “그래프”, “요청”을 선택하여, 더욱 다양한 분석을 할 수 있다.예를 들면, 동일한 시나리오를 “브라우저 연결 수”를 변경하며 테스트한 후, y-축에 “요청 수/초(평균)”을 설정하고, x-축에 “브라우저 연결 수”를 선택함으로써, “동시사용자”의 증가에 따른

시스템 확장 사이즈를 추정할 수 있다.

202


[그림 69] 테스트 그래프

203


4. 개발 후 – 배포와 관리

4.1. 배포

배포(Deployment)는 개발 및 테스트된 애플리케이션을 운용할 컴퓨터에 설치하는 과정을

의미한다. 애플리케이션 배포를 성공적으로 수행하려면, 사전에 배포 계획 및 시나리오를 철저히

수립해야 한다. 이 장에서는 .NET 애플리케이션을 배포할 때 고려해야 할 사항들에 대해서

알아보도록 한다.

4.1.1. 배포 단계

애플리케이션 배포는 물리적인 환경 상의 흐름과 과정 상의 흐름으로 크게 나누어 볼 수 있다.

4.1.1.1. 물리적 환경 상의 흐름

물리적인 환경 상에서 배포는 다음과 같은 순서로 일어나게 된다. 특수한 경우에는 테스트 환경과

이관 환경은 하나로 통합하여 수행될 수도 있다.개발 환경 애플리케이션을 개발한 후, 배포를 위한 패키징을 수행

개발툴이나 개발에 필요한 컴포넌트가 이미 설치되어 있음

테스트 환경 배포 패키지를 실제로 설치 후 기능 및 성능 테스트 수행

개발 환경에서는 수행되나 테스트 환경에서는 실행되지 않는 경우를

파악하고, 문제점을 조치해야 함

이관(Staging) 환경 실제 환경과 동일한 조건으로 구성한다.기존 시스템이 있는 경우에는 병행해서 운용할 필요가 있다.PreProduction 환경이라고 부르기도 한다.

실제(Production) 환경 실제 운용 환경으로 기존 시스템을 완전히 대치한다.이 시점에서는 설치를 취소하는 것은 불가능해진다.

4.1.1.2. 과정 상의 흐름단계 세부단계 내용

배포 계획 수립배포할 대상 및 내용 선정 무엇을 어디에 배포할 것인가?배포 전략 선정 어떻게 배포할 것인가?

구현 배포 패키지 작성 배포 전략에 따라 작성

유지 보수 버전관리 및 업그레이드 어떻게 업데이트할 것인가?

204


4.1.2. 배포 계획 수립

배포 계획은 물리적인 아키텍처와 애플리케이션의 종류에 따라서 크게 영향을 받는다. 개발한

내용 중에서 배포해야 할 요소를 수집하고, 각각을 어디에 배치할 것인지를 결정한다.

4.1.2.1. 배포 내용 선정

배포 내용을 선정하기 위해서는 전체 애플리케이션을 이루는 요소들을 구분하고, 이들 중에

무엇을 배포해야 할 것인지를 결정해야 한다.

4.1.2.1.1. 파일 및 폴더

애플리케이션에서 배포하는 파일의 유형은 다음과 같다.파일 유형 Windows 애플리케이션/서비스 웹 애플리케이션/서비스

실행파일(*.exe) XDLL(*.dll) X X구성 파일(*.config) X X데이터베이스 X X웹 페이지(*.htm, html)

X

웹 폼(*.aspx, *.ascx) X웹 서비스(*.asmx) XDiscovery 파일

(*.disco)X

XML 스키마(*.xsd) X*. Config 파일의 경우, 특정 컴퓨터(개발 환경, 테스트 서버)에 종속적인 내용이 되지 않도록

적절하게 변경한다. 예를 들어 데이터베이스 연결 문자열을 *.config에 두는 경우가 많은데, 이

값을 실제 Production 서버에 해당하는 연결 문자열로 변경해야 한다.

4.1.2.1.2. 어셈블리(Assembly)

어셈블리는 .NET에서 사용하는 배포, 버전관리, 재사용, 활성화 영역, 보안 권한 등의

기초단위이다. 어셈블리는 Manifest, 메타데이터, MSIL 코드, 리소스 등으로 이루어지며, 통상적으로는 단일 파일 어셈블리(Single File Assembly)로 구성되어 하나의 EXE나 DLL을

지칭하는 것이라고 간주하면 된다.일반적인 어셈블리는 Private 어셈블리(또는 Weak Name 어셈블리)라고 불리며, 애플리케이션

디렉터리에 배포된다. 즉, 애플리케이션을 구성하는 요소들이 같은 디렉터리(또는 그 하위

디렉터리) 안에 있어야 한다는 것을 의미한다.

205


여러 애플리케이션에서 공통적으로 사용되는 애플리케이션의 경우, GAC(Global Assembly Cache)에 넣어서 공유할 수도 있다. GAC에 등록하려면 반드시 강력한 이름(Strong name)으로

서명해야 한다는 것에 주의한다.어셈블리, GAC, 강력한 이름에 관한 자세한 설명은 MSDN을 참조하도록 한다.

COM 컴포넌트

애플리케이션을 개발하다보면 기존에 존재하는 COM 컴포넌트를 사용해야 하는 경우가 있다. COM 컴포넌트는 레지스트리에 등록되어야 하므로, 설치 프로그램을 제작해야 하는 것이

필수적으로 요구된다.

4.1.2.1.3. Serviced Component(COM+ 컴포넌트)

Serviced Component는 COM+를 사용하는 .NET 컴포넌트를 의미한다. 원칙적으로 COM+를

사용하려면 레지스트리 및 COM+ 카탈로그에 등록되어야 한다.그러나 Serviced Component의 경우, 컴포넌트의 메서드를 최초로 호출할 때 자동적으로 자기

자신을 등록(Self-Registration)하므로 별다른 등록 과정이 필요없다. 대신 이를 위해서는

Serviced Component를 강력한 이름으로 서명해야 한다는 것에 주의한다.

4.1.2.1.4. IIS 설정

ASP.NET 웹 애플리케이션의 경우, IIS에 가상 디렉터리를 만들고 애플리케이션 속성과 관련한

설정을 해줘야 한다. 또한 ASP.NET Worker Process와 관련하여 설정을 해야 하는데, IIS 5.x의

경우 Machine.config 파일을 수정하며, IIS 6.0의 경우는 IIS 내부에서 애플리케이션 풀의

속성을 변경해야 한다.

4.1.2.1.5. 레지스트리 설정

COM 컴포넌트 또는 Serviced Component 외에 별도로 레지스트리에 특정 값을 등록해서

사용하는 경우에는 설치 시에 레지스트리 값을 설정해야 한다.

4.1.2.2. 배포 대상 선정

배포 내용을 선정한 후에는 각각을 대상 컴퓨터에 어떻게 배치할 것인지를 결정한다. 대상이 되는

컴퓨터의 종류에 따라 다음과 같은 작업을 수행하게 된다.

4.1.2.2.1. 클라이언트

WinForm 클라이언트

클라이언트 애플리케이션 구동에 필요한 실행파일 및 DLL, 관련 파일

206


.NET Framework 3rd Party 컨트롤 등 각종 컴포넌트

ASP.NET 애플리케이션

기본적으로는 특별한 설치가 필요없음

WinForm 컨트롤을 사용하는 경우, .NET Framework이 필요

4.1.2.2.2. 웹 서버

.NET Framework 웹 애플리케이션 관련 파일(*.dll, *.aspx, *.ascx, *.asmx 등) 웹 애플리케이션 구성 파일(web.config) 각종 서버 사이드 컴포넌트(예 : Chart, Grid, Report 등)4.1.2.2.3. 애플리케이션 서버

.NET Framework COM+ 비즈니스 로직 컴포넌트

각종 서버 사이드 컴포넌트

4.1.2.2.4. 데이터베이스

데이터베이스 관련 파일(테이블, 저장 프로시저 등)4.1.2.3. .NET Framework의 배포

배포 내용 및 배포 대상에 따라 대상이 되는 컴퓨터에 .NET Framework를 설치해야 할 필요가

있다. 이 때, .NET Framework를 어떻게 설치할 것인지를 잘 고려해야 한다.

4.1.2.3.1. 사전 설치

개발된 애플리케이션과는 별도로 .NET Framework을 설치하는 것을 의미한다. 애플리케이션

배포를 위한 인프라가 갖추어져 있거나, 소수의 서버에 설치할 때 주로 사용된다. 사전 설치를

위한 방법에는 다음과 같은 것들이 있다. Microsoft Systems Management Server (SMS) 그룹 정책(Group Policy) 네트워크 공유

이 메일

인터넷 또는 인트라넷 웹 사이트

Microsoft 웹 사이트(예 : Windows Update)

207


4.1.2.3.2. 애플리케이션과 함께 설치

애플리케이션을 설치하기 전에, .NET Framework이 설치되어 있지 않으면 먼저 설치하는 것을

의미한다. 일반적으로 설치 패키지를 통해서 구현되며, 설치 패키지의 setup.exe BootStrapper 파일을 변경해서 작성하게 된다.Visual Studio .NET에 추가로 설치할 수 있는 Bootstrapper Plug-in을 설치하면, 설치

프로젝트를 만들 때 .NET Framework을 함께 설치할 수 있게 해준다. Bootstrapper Plug-in에

관련한 URL은 다음과 같다.

http://msdn.microsoft.com/vstudio/downloads/tools/bootstrapper/

4.1.2.4. 배포 전략 선정

배포 내용 및 대상 선정이 완료되면, 어떠한 방법을 통해서 배포할 것인지를 결정해야 한다. 애플리케이션을 배포하는 방법은 다음과 같이 3가지가 존재한다.

설치 패키지를 통한 배포

No-Touch 배포

파일 복사

각각의 3가지 방법에 대해서 자세히 알아보도록 하자.4.1.2.4.1. 설치 패키지를 통한 배포

일반적으로 애플리케이션을 배포할 때 가장 널리 사용되는 방법으로 애플리케이션을 설치

패키지를 작성하고, 설치 프로그램을 통해 컴퓨터에 설치하는 것을 말한다. 가장 대표적인 설치 패키지로는 Windows Installer(*.msi)가 있다. Windows Installer는

Windows Installer Service와 함께 구동되며, 이를 위해서는 대상 컴퓨터에 Windows Installer Service 2.0 이상이 설치되어 있어야 한다. Windows Installer는 애플리케이션 설치 시에 필요한 대부분의 기능을 지원하는데, 다음과 같다.

설치하기 전에 필요한 하드웨어 및 소프트웨어 점검

애플리케이션을 실행하기 위한 바탕 화면 및 메뉴 바로가기 생성

웹 애플리케이션의 경우, IIS 관련 설정(가상 디렉터리 생성, 애플리케이션 속성) 수행

파일 및 폴더 위치 관리

레지스트리 조작

파일 연관관계(File Associations) 생성

COM 및 COM+ 컴포넌트 설치

어셈블리를 GAC에 설치

설치 완료 후 사용자 정의 작업 수행

208

http://msdn.microsoft.com/vstudio/downloads/tools/bootstrapper/


버전 정보 유지, 패치와 업그레이드가 올바른 순서로 설치되었는지 확인

다계층 애플리케이션인 경우, 각각의 물리적 계층에 맞도록 별도의 설치 패키지를 작성해야

한다는 것에 주의한다.

설치 패키지 배포

작성된 설치 패키지를 배포하는 방법은 다음과 같다. Active Directory의 그룹 정책(Group Policy) 기능

Microsoft Systems Management Server(SMS) 기타(네트워크 서버, 웹 서버, CD와 같은 각종 미디어, 이메일 첨부 등)

설치 패키지 작성 도구

Windows Installer 설치 패키지를 작성하기 위한 도구는 다음과 같은 것이 있다. Visual Studio .NET의 설치 프로젝트

Visual Studio .NET 내에 포함되어 있으며, 비교적 간단한 설치 패키지를 작성할 수 있다. InstallShieldWindows Installer 뿐만 아니라 다른 형식의 설치 패키지도 작성 가능하며, 설치 패키지를 쉽게

작성할 수 있는 다양한 마법사를 제공한다. 최근 버전의 경우, Visual Studio .NET 내에 통합되어

프로젝트 마법사를 제공한다.제품과 관련한 정보는 InstallShield 웹 사이트(http://www.installshield.com)를 참조한다.

Wise for Visual Studio .NETVisual Studio .NET 내부에서 설치 패키지를 만들 수 있게 해주는 도구이다.제품과 관련한 정보는 Wise 웹 사이트(http://www.wise.com)를 참조한다.4.1.2.4.2. No-Touch 배포

No-Touch 배포는 Windows Form 기반의 애플리케이션을 배포할 수 있는 .NET Framework의

기능 중 하나로, 이 배포 방법을 사용하는 클라이언트를 스마트 클라이언트(Smart Client)라고

부르기도 한다.

No-Touch 배포 시나리오

애플리케이션 파일(실행파일 및 DLL)을 웹 서버에 올려놓는다. 사용자가 HTTP를 사용하여 애플리케이션 경로(예: http://www.server.com/app.exe)로 접속한다.

애플리케이션이 최초 구동하는데 필요한 파일이 .NET Framework 어셈블리 캐시

다운로드 폴더(Document and Settings\<UserName>\Local Settings\Application Data\Assembly\dl2) 로 다운로드 된다. 애플리케이션에서 사용하는 추가적인 리소스 파일이

자동적으로 다운로드 된다.

No-Touch 배포의 장점

209

http://www.server.com/app.exe

http://www.wise.com/

http://www.installshield.com/


Windows 애플리케이션의 풍부한 UI와 웹 애플리케이션의 뛰어난 유지보수성을 가짐

각종 리소스는 필요 시에만 다운로드 되고, 다운 받은 후에는 캐시됨

애플리케이션을 설치하는 과정이 자동적으로 이루어짐

웹 서버 쪽만 업데이트하면 버전 확인 후 다시 다운로드 받아서 갱신

No-Touch 배포가 적합하지 않은 경우

네트워크 상황이 좋지 못한 경우

애플리케이션을 오프라인에서 사용해야 할 필요가 있는 경우

임시 인터넷 파일 폴더에 저장되므로 오프라인에서도 구동할 수 있긴 하나, 다운로드 되지 않은

기능은 수행할 수 없다. 바로가기 만들기, 드라이버 설치, COM 컴포넌트 등록 등이 필요한 경우

보안 정책을 설정하기 까다로운 경우

애플리케이션 구성요소를 GAC에 배포해야 할 필요가 있는 경우

주의사항

No-Touch 배포를 사용하는 애플리케이션의 경우, 애플리케이션을 설계 및 디자인 할 때부터 미리

고려를 하는 것이 좋다. No-Touch 배포를 수행하기 위해서는 보안 정책 및 구성 파일 관리와 같은

여러가지 고려사항이 있으므로, 애플리케이션이 완성된 후에는 이러한 요소를 변경하기 까다로워

진다는 것에 주의한다.

4.1.2.4.3. 파일 복사

웹 애플리케이션의 경우에 가장 흔히 사용되는 방법으로 파일을 서버에 그대로 복사하는 것을

말한다. 이 방법은 별도의 배포 패키지 작성이나 설정이 필요 없으므로 가장 간편한 방법이라고

볼 수 있다.서버 애플리케이션의 경우, 관리자에 의해 제어되고 관리되므로 이러한 방법이 가장 잘 들어 맞을

수 있다. 대신 이 경우 설치 패키지에서 수행할 수 있는 각종 작업(레지스트리 설정, COM 컴포넌트 등록 등)을 수동으로 수행해야 한다는 것에 주의한다.파일 복사는 다음과 같은 3가지 방법을 통해서 수행될 수 있다.

Microsoft Application Center 2000웹 팜 환경에서 유용하며, 여러 대의 서버에 파일을 한번에 복사하고 서로 간에 동기화를 수행할

수 있다. VS .NET의 프로젝트 복사 기능

웹 애플리케이션에서만 적용가능하며, FrontPage Extension 권한이 있는 경우, 웹

프로젝트에서 배포해야 하는 파일만 선별하여 특정 웹 서버로 배포가 가능하다. 수동 파일 복사

직접 파일 복사를 수행한다.

210


4.1.3. 배포 전략 구현

배포 계획이 수립되면 이에 따라 실행에 옮기게 된다. No-Touch 배포나 파일 복사의 경우에는

특별한 내용이 없이 수행을 하면 되지만, 설치 패키지의 경우는 패키지를 만드는 작업이

필요하므로 이를 중점적으로 설명하도록 하겠다.

4.1.3.1. 설치 패키지

설치 패키지를 만드는 방법에는 여러가지 툴이 있지만, 여기서는 Visual Studio .NET에 포함된

설치 프로젝트를 사용하는 것을 기준으로 설명한다.

4.1.3.1.1. 설치 프로젝트 생성

새 프로젝트를 만든다. [프로젝트 형식]에서 [설치 및 배포 프로젝트]를 선택한다. Windows 애플리케이션이나 컴포넌트, 서비스 등을 설치하는 경우에는 템플릿에서 [설치 프로젝트]를

선택하고, 웹 애플리케이션이나 웹 서비스의 경우에는 [웹 설치 프로젝트]를 선택한다(나머지

템플릿에 대해서는 MSDN을 참조하기 바란다).

[그림 70] 설치 프로젝트 추가

[확인]을 누르면 설치 프로젝트가 생성된다. 프로젝트 속성을 선택해보면, 여러가지 속성들이

나타나는데, 각 속성값을 적절하게 변경한다. 통상 Author, Manufacturer를 회사 이름으로

지정하며, ProductName 및 Title을 변경해야 한다. 참고로 웹 설치 프로젝트를 선택했을 경우는

추가적인 속성값들이 존재한다.

211


[그림 71] 설치 프로젝트 속성

4.1.3.1.2. 파일 시스템 설정

설치 프로젝트를 생성하면 파일 시스템 탭이 나타난다. 만약 파일 시스템 탭이 보이지 않으면

솔루션 탐색기에서 설치 프로젝트를 오른쪽 클릭하고, [보기]->[파일 시스템]을 선택한다.

[그림 72] 파일 시스템 탭

기본적으로 왼쪽에 3개의 폴더가 생성되어 있는 것을 알 수 있다. 파일 시스템은 각각의 폴더에

설치할 파일을 지정해주면 된다. 만약 다른 폴더를 추가하고 싶으면, [대상 컴퓨터의 파일 시스템]을 오른쪽 클릭하고 특수 폴더를 추가한다. 즉, 만약 GAC에 설치하고 싶은 파일이 있으면 [전역

어셈블리 캐시 폴더]를 추가하면 된다.

212


[그림 73] 특수 폴더 추가

해당 폴더에 파일을 설치하려면, 폴더를 선택한 후, 오른쪽 창에서 오른쪽 클릭을 하고, [추가]를

선택한다. [새 바로 가기 만들기]를 선택해서 바탕화면이나 프로그램 메뉴에 바로가기를 만들

수도 있다.

[그림 74] 폴더에 항목 추가

추가할 수 있는 유형은 다음과 같다. 폴더 : 해당 폴더 아래에 하위 폴더를 추가한다. 프로젝트 출력 : 같은 솔루션 내의 다른 프로젝트를 빌드할 때 나오는 결과물을 추가

파일 : 이미 만들어져 있는 기존 파일. 어셈블리(*.exe, *.dll)이 아닌 파일을 추가해야 할

때 선택하는 것이 좋다. 어셈블리 : 이미 만들어져 있는 기존 어셈블리. 어셈블리에서 다른 어셈블리를 참조할

경우 다른 어셈블리도 함께 추가된다.프로젝트 출력을 선택했을 경우에는 다음과 같은 창이 나타난다.

213


[그림 75] 프로젝트 출력 그룹 추가

일반적인 경우에는 기본 출력만을 선택하면 된다. 나머지 파일들은 필요에 따라서 선택적으로

추가하기 바란다. 다음은 파일 시스템에 파일이 추가된 예이다. 프로젝트 출력이나 어셈블리를

선택한 경우, 종속성에 따라 참조하고 있는 어셈블리들을 자동으로 추가한다.

[그림 76] 추가된 파일

4.1.3.1.3. 시작 조건 지정

설치를 시작하기 위한 조건을 지정할 수도 있다. 설치 프로젝트를 오른쪽 클릭하고, [보기]->[시작 조건]을 선택한다.

[그림 77] 검색 추가

[대상 컴퓨터 검색]을 오른쪽 클릭하고, 시작 조건을 실시할 검색 내용을 추가한다. 파일 검색(특정 파일의 존재유무), 레지스트리 검색(특정 레지스트리 키 및 값), Windows Installer 검색(기존에 설치된 패키지 유무)를 추가할 수 있다. 다음 그림은 각각의 조건을 추가했을 때 속성창의

214


모습이다.

[그림 78] 검색 - 시작 조건 속성

다음은 각 검색의 유형에 따른 필수 속성 값에 대한 설명이다.검색 유형 필수 속성 설명

파일 검색 FileName 검색할 파일 이름

Folder 파일 검색을 시작할 폴더

레지스트리 검색 Root 레지스트리를 검색할 루트

RegKey 검색할 레지스트리 키

Value 검색할 레지스트리 값 (Optional)Windows Installer 검색

ComponentId 검색할 컴포넌트의 GUID

검색을 추가했으면 [시작 조건]을 오른쪽 클릭하고, [시작 조건 추가]를 선택한다.

[그림 79] 시작 조건 속성

Condition에서는 위에서 추가한 검색의 Property를 지정하고, Message에는 시작 조건이 false일 때, 보여줄 메시지를 지정한다.

215


4.1.3.1.4. 레지스트리에 추가

레지스트리에 키를 만들거나 값을 추가하라면, 솔루션 탐색기에서 설치 프로젝트를 오른쪽

클릭하고 [보기]->[레지스트리]를 선택한다.

[그림 80] 시작 조건 속성

레지스트리 루트를 선택하고, 하위 키를 선택한다. 위 그림에서 [Manufacturer]는 설치 프로젝트

속성 중에서 Manufacturer를 의미한다. 해당 키 아래에 새로운 키를 만들거나, 값을 추가하면

된다.

4.1.3.1.5. 파일 형식 설정

파일 형식(File Association)은 특정 확장자를 가진 파일과 애플리케이션 간에 연관 관계를

맺어주는 것을 의미한다. 파일 형식을 설정하려면, 설치 프로젝트를 오른쪽 클릭하고 [보기]-[파일 형식]을 선택한다.

[그림 81] 파일 형식 속성

[대상 컴퓨터의 파일 형식]을 오른쪽 클릭하고 [파일 형식 추가]를 선택한다. 파일 형식 속성에서

Command에는 파일과 연관시킬 실행 파일을, Extensions에는 확장자를 작성한다.파일 형식을 오른쪽 클릭하고, [작업 추가]를 선택하여 이 확장명에 연관시킬 동사(Verb)를

추가로 지정할 수도 있다.

216


4.1.3.1.6. 사용자 지정 작업

설치 및 제거 간에 사용자 지정 작업이 수행되도록 할 수도 있다. 설치 프로젝트를 오른쪽

클릭하고, [보기]->[사용자 지정 작업]을 선택한다.

[그림 82] 사용자 지정 작업

이후 사용자 지정 작업을 포함하고 있는 *.dll이나 exe, 프로젝트 출력을 선택한다.사용자 지정 작업에 관한 자세한 사항은 MSDN을 참조하도록 한다.

4.1.3.1.7. 사용자 인터페이스

설치 간에 보여지는 사용자 인터페이스를 변경할 수도 있다. 설치 프로젝트를 오른쪽 클릭하고, [보기]->[사용자 인터페이스]를 선택한다. 설치 과정 상에 보이는 대화상자를 추가, 수정, 삭제할

수 있으며, 순서를 변경할 수 있다.

[그림 83] 사용자 지정 작업

4.1.3.1.8. 설치 패키지 빌드

설치 프로젝트를 오른쪽 클릭하고, [속성]을 선택한다.

217


[그림 84] 설치 프로젝트 속성

각 항목들을 적절하게 변경하고, [확인]을 누른다. 항목들에 대한 자세한 설명은 MSDN을

참조하도록 한다.설치 패키지를 빌드하는 방법은 일반 프로젝트와 동일하게, [빌드] 메뉴에서 해당 프로젝트를

빌드하도록 선택하면 된다. 빌드가 완료되면, Debug/Release 폴더 아래에 msi와 setup.exe Bootstrapper 파일이 생성된다.

4.1.3.2. No-Touch 배포4.1.3.2.1. 웹 서버에 배포

No-Touch 배포에서는 애플리케이션을 빌드한 결과물을 웹 서버의 가상 디렉터리 상에

올려놓기만 하는 것 외에는 별다른 작업이 필요하지 않다. 즉, 애플리케이션을 실행하기 위한

*.exe와 실행 파일이 참조하는 *.dll 및 기타 리소스 파일들을 가상 디렉터리에 복사한다. No-Touch 배포에서는 실제 클라이언트 상에서 실행되는 것과 마찬가지 개념이므로, 각종 환경

설정을 클라이언트 기준으로 해야 한다는 것에 주의한다.

4.1.3.2.2. 클라이언트에서의 실행

클라이언트에서 No-Touch 배포 후 애플리케이션을 실행하는 방식은 크게 3가지가 있다.

URL 실행 애플리케이션(URL-launched Application) 방식

URL 경로로 실행파일(*.exe)을 호출하면, 실행 파일 및 실행 파일이 참조하는 어셈블리가

218


다운로드 되어서 실행된다.

애플리케이션 스텁(Application Stub) 방식

애플리케이션을 로딩하기 위한 간단한 스텁(stub) 실행 파일을 배포하고, 이 실행 파일 내에서

Assembly.LoadFrom() 메서드를 호출하여 필요한 어셈블리를 로드한다.InternetExplorer Winform Control Embedded 방식

Winform 컨트롤을 Embed 하고 있는 웹 페이지를 Internet Explorer상에서 Request 하면, 해당 페이지가 IE 상에 로딩되면서, 함께 Embed 되어 있는 Winform 컨트롤이 다운로드 되어

실행된다. 구동 방식은 앞서 설명한 URL 실행 어플리케이션과 동일하다.

4.1.3.2.3. 보안 문제

No-Touch 배포 시에는 애플리케이션 코드를 실행하는데 필요한 보안 권한을 조절해 주어야 한다

.NET은 어셈블리에 코드 접근 권한(Code Access Security)를 적용하여, 네트워크 경로에서

다운로드 받은 애플리케이션에 대해서는 기본적으로 신뢰하지 않는다. 그러므로, 해당

어셈블리의 신뢰수준을 조정하여 애플리케이션이 제대로 실행되도록 설정해줘야 한다.이러한 보안 정책 조정은 [제어판]-[관리도구]-[.NET Framework 구성 도구]에서 런타임 보안

정책을 조정하면 되지만, 이를 개별 사용자에게 일일이 하라고 하는 것은 불가능에 가깝다. 그러므로 보안정책을 설정해주기 위한 방법을 제공해야 할 필요가 있다.

.NET Framework 구성 도구를 활용

.NET Framework 구성 도구의 런타임 보안 정책에서는 보안 정책 배포 패키지(*.msi)를 만들 수

있다. 보안 정책을 적용하기 위해서는 이 정책 패키지를 배포하고, 설치하도록 하면 된다. 이

패키지의 단점은 컴퓨터에 기존에 설치되어 있는 보안 정책을 완전히 삭제해버리고, 정책 패키지

안의 내용으로 덮어써버린다는 것이다. 회사 전체의 컴퓨터 및 운용되는 애플리케이션을

강력하게 통제할 수 있는 경우에는 적용이 가능하다.

CASPOL.EXE을 활용

.NET에서는 코드 접근 권한을 설정할 수 있는 커맨드라인 유틸리티인 CASPOL.EXE을 제공한다. 그러므로 설치 후 동작으로 CASPOL.EXE을 실행하는 설치 패키지를 제작하여 사용자에게

배포함으로써 보안 정책을 설정할 수 있다. CASPOL.EXE을 활용할 때 장점은 기존 보안 정책을

그대로 두고, 새로운 보안 정책을 추가할 수 있다는 것이다.

배포 패키지 설치 시 Custom Action 을 통한 런타임 보안 정책 수정

어플리케이션의 보안 정책을 배포 패키지의 Custom Action 을 통하여, 설치시에

어플리케이션에 적합한 정책 수준에 대한 설정을 코딩을 통하여 제어 한다. 또한 해당 배포

패키지의 삭제 시에 자동적으로 설정된 정책 수준을 이전으로 되돌릴 수 있게 구현 한다.

219


4.1.3.2.4. HTTP 를 통한 어플리케이션의 구동

No-Touch 배포를 할 때 고려해야 할 사항은 애플리케이션이 HTTP를 통하여 배포되기 때문에

해당 어플리케이션이 비록 다운로드 후 클라이언트 상에서 구동이 되더라도, 어플리케이션의

비즈니스 로직 및 데이터 엑세스 방식에 있어서도 HTTP를 통한 엑세스 방식을 고려해야 한다. 즉, 일반적인 CS 어플리케이션의 방식으로의 구현이 아니라, 웹 서비스 혹은 .NET Remting을 통한

Serviced Oriented Architecture(SOA) 기반의 구현이 요구된다

4.1.3.3. 파일 복사

파일 복사의 경우, 별다른 작업이 없으며 해당 폴더로 관련 파일들을 복사해주면 된다. 대신

여러가지 설정 작업을 수동으로 해줘야 한다는 것에 주의한다. 새로운 컴퓨터로 파일 복사를 통해

설치를 할 때는 설치 순서를 꼼꼼하게 점검한 다음에 실시하도록 한다. 일반적으로 점검해야 할

사항들은 다음과 같다. IIS 환경 설정

DB 연결 문자열 (오라클의 경우, 오라클 클라이언트 및 TNS 설정 포함) DTC 사용 시, 방화벽 설정 문제

레지스트리 설정

3rd Party 컴포넌트 설치

기타

4.1.4. 유지 보수

애플리케이션을 배포한 후, 다음과 같은 이유로 애플리케이션을 업그레이드 해야 할 필요가 있다. 버그 수정

기존 기능 향상

새로운 기능 추가

이 절에서는 .NET Framework이 애플리케이션 유지 보수와 제공하는 여러가지 새로운 기능을

알아보고, 유지 보수 전략을 수립해 보기로 한다.

4.1.4.1. 유지 보수 전략 수립

애플리케이션을 업데이트할 범위에 따라 업그레이드 레벨을 선정하고, 레벨에 맞춰서 업그레이드

전략을 수립해야 한다.

220


4.1.4.1.1. 업그레이드 레벨

애플리케이션 업그레이드 레벨은 다음과 같이 분류할 수 있다. 메이저 업그레이드(Major Upgrade)

새로운 기능을 포함하고 있거나, 커다란 변경이 일어난 경우.Version 1.0에서 메이저 업그레이드가 된 경우에는 Version 2.0이 된다.

마이너 업그레이드(Minor Upgrade)사소한 변경이 일어난 경우.Version 1.0에서 마이너 업그레이드가 된 경우에는 Version 1.1이 된다.

소규모 업데이트(Small Update)패치나 버그 수정할 내용이 있는 경우.통상적으로 소규모 업데이트 시에는 버전 번호를 증가시키지 않는다.

4.1.4.1.2. 업그레이드 선택 사항

애플리케이션 업그레이드를 배포할 때는 다음 중 하나를 선택할 수 있다. No-Touch 배포

Windows Installer 설치 패키지 배포

파일 복사

자동 업데이트 구성

위 선택사항들에 대해 좀 더 자세히 알아보자.

No-Touch 배포

No-Touch 배포에서는 변경된 파일을 웹 서버에 올려놓기만 하면, 클라이언트가 다음에

애플리케이션을 실행할 때 필요한 새 파일들을 다운로드하게 된다. 웹 서버에는 변경된 파일만을

올려놓거나, 아니면 전체를 새로 빌드한 후 전체 내용을 갱신할 수도 있다.No-Touh 배포는 비록 그 방식이 웹 어플리케이션과 유사하지만, 클라이언트가 애플리케이션을

사용하고 있는 도중에는 서버사이드에서 어셈블리를 갱신 하였다고 하더라도, 애플리케이션이

현재 호스트 되고 있는 IEExec.exe 가 새로 구동되기 이전에는 이전에 다운로드 되었던

어셈블리가 실행된다. 즉, 갱신을 위해서는 클라이언트가 인터넷 익스플로러를 새로 구동시키거나, 현재 실행되어 있는

어플리케이션을 종료하고 새로 실행시켜야만 갱신이 반영될 수 있다.또한 LoadFrom 을 통하여 로딩되는 어셈블리가 참조하고 있는 어셈블리가 갱신되는 경우, LoadFrom을 통하여서는 해당 어셈블리가 현재 갱신되었는지 여부를 알 수 있는 방법이 없다. 그러므로, 아래와 같은 환경 설정 파일을 통하여 새로운 버전의 어셈블리로 실행시에 Binding Redicrect 할 수 있도록 설정해 주어야 한다

221


<dependentAssembly> <assemblyIdentity name="AssemblyName" publicKeyToken="Strong key Token" culture="neutral" />

<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.0.1"/></dependentAssembly>

Windows Installer 설치 패키지 배포

Windows Installer를 사용하는 경우에는 다음 중 한가지를 선택할 수 있다. 새로운 배포 프로젝트를 만든다.이 경우, 배포 프로젝트의 GUID가 달라지므로 Windows Installer의 업그레이드 관련 기능을

사용할 수 없다. Major 업그레이드 시에 많이 사용한다.

기존 배포 프로젝트를 업그레이드하여 다시 빌드한다.기존 프로젝트를 그대로 사용하면서 버전 번호를 변경한다. 이 경우 Windows Installer의

업그레이드 관련 기능을 활용할 수 있다.Minor 업그레이드 시에 많이 사용한다.

패치 패키지를 만든다.작은 변경사항만을 담은 패키지를 만들어서 기존에 설치된 애플리케이션에 적용한다.Minor 업그레이드나 소규모 업데이트 시에 많이 사용한다.

Visual Studio .NET에서는 패치 패키지를 만드는 기능을 아직 제공하지 않는다.이를 위해서는 Windows Installer Platform SDK 도구나 3rd Party 도구를 사용해야 한다.

파일 복사

.NET Framework는 Shadow Copy를 지원하므로, 실행 중인 어셈블리를 그대로 덮어 쓸 수

있다. 특히 ASP.NET 애플리케이션의 경우 애플리케이션이 사용하는 어셈블리에 변경이

일어나면, 자동적으로 애플리케이션을 종료한 후 새로운 어셈블리를 로드한다.웹 애플리케이션의 경우 웹 팜(Web Farm) 환경에서 구동된다면, Application Center와 같은

제품을 사용하여 배포할 수 있다.

자동 업데이트

자동 업데이트란 특정 시점에 업데이트의 존재 유무를 확인하고, 업데이트가 있으면 다운로드

후에 적용하는 형식의 애플리케이션을 말한다.구현에 대한 자세한 내용은 MSDN에서 Application Updater Application Block을 참조한다.

222


4.1.4.2. 버전 관리

.NET에서는 어셈블리 단위로 버전 관리를 수행하므로, 어셈블리의 버전 정보를 제대로

유지해줘야만 업데이트 시에 정확하게 반영이 가능하다.기본적으로 Visual Studio .NET에서 프로젝트를 생성하면, 프로젝트마다 AssemblyInfo.cs (또는 AssemblyInfo.vb) 파일을 생성한다. 여기서 버전 정보를 나타내는 곳은 다음과 같다.

[assembly: AssemblyVersion("1.0.*")]위에서 보는 바와 같이 기본적으로 1.0.*가 지정되어 뒤의 Revision 및 Build 번호는 랜덤하게

생성되게 된다. 명확한 버전 관리를 위해서는 기본값 대신에 명시적으로 버전 번호를 지정하도록

한다.개발 시에는 버전을 모두 고정 시킨 후 개발을 진행하는 것이 팀 단위 개발에서 빈번히 발생하는

어셈블리 종속성 문제를 해결 할 수 있다.

[assembly: AssemblyVersion("1.0.0.1")]

4.2. 운영 및 관리

애플리케이션 배포가 완료되면 이를 운영(Operation)하고 관리(Management)하는 과정으로

넘어가게 된다. 이 장에서는 애플리케이션 운영 및 관리 시에 사용해야 하는 도구들과

고려사항들에 대해서 알아보도록 한다.

4.2.1. 시스템 관리

4.2.1.1. 인터넷 정보 서비스

IIS (Internet Information Service) 웹 서버는 [제어판]->[관리도구]->[인터넷 정보 서비스

관리]를 선택하여, MMC 스냅인을 사용해서 관리할 수 있다. 다음 그림은 인터넷 정보 서비스

스냅인을 나타낸 것이다.

223


[그림 85] IIS 5.x

[그림 86] IIS 6.0 (Windows 2003)

Windows 2003의 IIS 6.0에는 [응용 프로그램 풀] 및 [웹 서비스 확장]이라는 항목이 왼쪽에

추가되어 있음을 알 수 있다. 자세한 사항은 IIS 6.0 도움말을 참조하도록 한다.이 관리자를 사용하면 가상 디렉터리를 추가, 수정, 삭제하거나 웹 사이트 및 웹 애플리케이션에

관련한 여러가지 속성(경로, 보안 등)을 조정할 수 있다.

4.2.1.2. 구성 요소 서비스

Windows 2000에는 COM+ 1.0, Windows XP 및 2003에는 COM+ 1.5가 탑재되어 있으며, 이를 관리하기 위한 [구성 요소 서비스] 관리 도구를 제공한다. 구성 요소 서비스를 사용하면

224


컴퓨터에 설치되어 있는 COM+ 애플리케이션 및 컴포넌트를 보고, 각각에 대한 설정을 변경 및

모니터링할 수 있다.

[그림 87] 구성 요소 서비스

[COM+ 응용 프로그램]에서 특정 애플리케이션을 선택하고, 등록정보를 열어 여러가지 설정을

조정할 수도 있다. 기본적으로 .NET으로 작성된 Serviced Component는 개발자가 지정한

특성에 따라서 설정되지만, 설치 후에 운영자가 설정(보안, ID, 활성화 유형, 풀링 등)을 변경할

수도 있다.

[그림 88] COM+ 애플리케이션 등록 정보

COM+ 애플리케이션에 속한 컴포넌트(.NET에서는 클래스)들에 대해서 여러가지 속성(트랜잭션,

225


동기화 등)을 설정할 수 있다.

[그림 89] COM+ 컴포넌트 등록 정보

분산 트랜잭션 코디네이터에서는 현재 실행 중인 트랜잭션 목록과 트랜잭션 통계를 살펴볼 수

있다. 트랜잭션 목록에서는 현재 존재하는 트랜잭션을 살펴보고, 임의로 커밋/중단/무시할 수도

있다.

[그림 90] 트랜잭션 목록

226


[그림 91] 트랜잭션 통계

4.2.2. 모니터링

4.2.2.1. 이벤트 로그

이벤트 로그에는 애플리케이션, 보안, 시스템에 관한 로그뿐만 아니라 사용자 정의 로그도 기록할

수 있다. 이벤트 뷰어를 사용하면 이벤트 로그에 기록된 내용을 볼 수 있다.

[그림 92] 이벤트 뷰어

오류로 기록된 내용에 대해서는 내용을 확인한 후 필요한 조치를 수행하고, 관리자 차원에서

해결될 문제가 아닌 경우에는 개발팀에게 통보해야 한다.

227


4.2.2.2. 작업 관리자

작업 관리자를 사용하여 실행 중인 프로그램 및 프로세스, CPU / 메모리 / 네트워크 사용현황등을

모니터할 수 있다.

[그림 93] 작업 관리자

4.2.2.3. 성능 모니터

작업 관리자에서 제공해주는 간단한 사항 외에 보다 자세한 시스템 사용 현황을 모니터링 하려면

성능 모니터를 사용한다.

[그림 94] 성능 모니터

228


성능 모니터에서는 모니터링하고자 하는 카운터를 임의로 추가할 수 있다. 카운터 추가에서는

성능 개체를 선택하고, 목록에서 카운터를 선택한다.

[그림 95] 카운터 추가

성능 모니터의 내용은 실시간으로 보는 것 뿐만 아니라 로그 기록으로도 남길 수 있다. 또한

Microsoft Operation Manager와 같은 제품을 사용하면, 여러 대 컴퓨터의 성능 모니터 내용을

한곳에서 통합해서 볼 수도 있다.

229

Date post:	28-Dec-2019
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

winkey.tistory.com · Web view[그림 21] 팀 개발 프로세스와 구성원, 서버 개발 팀...

Documents