도움말 번역입니다



부트스트래퍼란 무엇인가?




부트스트래퍼Bootstrapper란 프리즘 라이브러리를 사용하여 빌드된 응용프로그램의 초기화에 책임이 있는 클래스입니다. 부트스트래퍼를 사용함으로써, 당신은 프리즘 라이브러리 컴포넌트들이 응용프로그램과 연결되는 방식을 더 많이 제어할 수 있습니다.


프리즘 라이브러리는 기본 추상 Bootstraper 기저 클래스를 포함하는데, 이는 다른 컨테이너들을 사용하기 위해서 특수화될 수도 있습니다. 부트스트래퍼 클래스들 상의 많은 메서드들은 가상 함수입니다. 당신은 이러한 메서드들을 당신만의 커스텀 부트스트래퍼 구현을 위해 적절하게 재정의할 수 있습니다.



프리즘 라이브러리는 몇 개의 부가적인 기저 클래스들을 제공하는데, 이것들은 Bootstrapper 를 상속합니다. 그리고 대부분의 응용프로그램들에 적합한 기본 구현들을 가지고 있습니다. 당신의 응용프로그램 부트스트래퍼에서 구현하도록 남겨진 스테이지는 쉘을 생성하고 초기화하는 것 뿐입니다.


의존성 주입Dependency Injection



프리즘 라이브러리를 사용해 빌드된 응용프로그램들은 컨테이너가 제공하는 의존성 주입에 의존합니다. 이 라이브러리는 유니티 응용프로그램 블락( Unity Application Block, Unity )이나 관리되는 확장성 프레임워크( Managed Extensibility Framework, MEF ) 를 사용해 동작하는 어셈블리들을 제공하며, 그것은 당신이 다른 의존성 주입 컨테이너들을 사용하는 것을 허용해 줍니다. 부트스트래핑 과정 중의 일부는 이 컨테이너를 구성하고 컨테이너에 타입들을 등록하는 것입니다.


프리즘 라이브러리는 UnityBootstrapperMefBootstrapper 클래스들을 포함하는데, 이것들은 Unity 나 MEF 를 사용하기 위해서 필요한 거의 대부분의 기능들을 당신의 응용프로그램 내의 의존성 주입 컨테이너로서 구현합니다. 이전 그림에서 보여 준 이 스테이지와는 별개로, 각 부트스트래퍼들은 자신의 컨테이너가 무엇이냐에 따라 몇 개의 단계를 추가합니다.


Shell 생성하기



일반적인 윈도우즈 프리젠테이션 파운데이션( Windows Presentation Foundation, WPF ) 응용프로그램에서, 메인 윈도우를 띄우는 App.xaml 파일에서 스타트업 통합 리소스 식별자( Uniform Resource Identifier, URI )가 지정됩니다. 실버라이트 응용프로그램에서는, 응용프로그램상의 RootVisual  속성이 App.xaml 파일의 코드 비하인드에서 설정됩니다.


프리즘 라이브러리를 사용해서 생성된 응용프로그램에서, 쉘이나 메인 윈도우를 생성하는 책임은 부트스트래퍼에게 있습니다. 그것은 쉘이 영역 관리자Region Manager와 같은 서비스들에 의존하며, 그것들은 쉘이 디스플레이되기 전에 등록될 필요가 있기 때문입니다.


중요한 결정들



응용프로그램에서 프리즘 라이브러리를 사용하겠다고 결정한 후에, 몇 가지 부가적인 결정들을 해야 할 필요가 있습니다:


  • 의존성 주입 컨테이너를 위해 MEF 컨테이너를 사용할지 Unity 컨테이너를 사용할지, 아니면 다른 컨테이너를 사용할지 결정해야 할 것입니다. 이는 당신이 사용해야만 할 부트스트래퍼 클래서가 무엇인지를 결정하게 할 것이고, 다른 컨테이너를 위한 부프트스트래퍼를 생성할 필요가 있는지 여부를 결정하게 할 것입니다.
  • 응용프로그램에서 사용하기 원하는 특별한 서비스들이 있는지 생각해 봐야 합니다. 그 서비스들은 컨테이너에 등록될 필요가 있습니다.
  • 어떤 빌트인 로깅 서비스가 당신의 필요에 맞는지, 혹은 다른 로깅 서비스를 생성해야할 필요가 있는지 결정해야 합니다.
  • 응용프로그램이 모듀들을 어떻게 발견할지를 결정해야 합니다: 명시적인 코드 선언들을 통해서, 디렉토리 스캐닝을 통해 발견된 모듈들 상의 코드 애트리뷰트들을 통해서, configuration 을 통해서, XAML 을 통해서.
나머지 챕터들은 좀 더 세부적인 내용을 제공합니다.

코드 시나리오들



스타트업 시퀀스를 생성하는 것은 프리즘 응용프로그램을 빌드하는 매우 중요한 과정입니다. 이 섹션은 부트스트래퍼를 생성하는 방법과, 쉘을 생성하고 의존성 주입 컨테이너를 구성하고 응용프로그램 수준 서비스들을 등록하기 위해서 부트스트래퍼를 커스터마이즈하는 방법에 대해서 설명합니다. 그리고 모듈들을 로드하고 초기화하는 방법에 대해 설명합니다.


응용프로그램을 위해서 부트스트래퍼 생성하기



의존성 주입 컨테이너로서 Unity 나 MEF 를 선택했다면, 응용프로그램을 위한 간단한 부트스트래퍼를 생성하는 것은 쉽습니다. MefBootstrapperUnityBootstrapper 를 상속하는 새로운 클래스를 생성하기만 하면 될 것입니다. 그리고 CreateShell 메서드를 구현합니다. 추가적으로 InitializeShell 메서드를 특별한 쉘 초기화를 위해 재정의할 수도 있습니다.


CreateShell 메서드 구현하기



CreateShell 메서드는 개발자가 프리즘 응용프로그램을 위한 최상위 수준 윈도우를 지정할 수 있도록 허용합니다. 그 쉘은 보통 MainWindow 이거나 MainPage 입니다. 이 메서드를 응용프로그램의 쉘 클래스들 중의 인스턴스 중 하나를 반환하도록 구현하십시오. 프리즘 응용프로그램에서, 당신은 쉘 오브젝트를 생성하거나 그것을 컨테이너로부터 가지고 올 수 있습니다. 이는 응용프로그램의 요구사항에 의존합니다.


ServiceLocator 를 사용해서 쉘 오브젝트를 가지고 오는 예제가 아래 코드 예제에서 보여집니다.



노트 :


당신은 종종 특정 의존성 주입 컨테이너 대신에 ServiceLocator 가 타입들의 인스턴스들을 가지고 오기 위해서 사용되는 것을 보게 될 것입니다. ServiceLocator 는 컨테이너를 호출함으로써 구현되므로, 컨테이너 불가지론적 코드를 위해서는 그것이 좋은 선택입니다. 당신은 ServiceLocator 대신에 컨테이너를 직접적으로 참조하고 사용할 수도 있습니다.


InitializeShell 메서드 구현하기



쉘을 생성했다면, 쉘이 디스플레이될 준비가 되었는지를 명확하게 하기 위한 초기화 단계를 수행할 필요가 있습니다. 당신이 WPF 를 작성하느냐 실버라이트를 작성하느냐에 따라, InitializeShell 메서드 구현은 다양해질 것입니다. 실버라이트 응용프로그램을 위해서, 당신은 아래에 보이는 것처럼, 응용프로그램의 visual root 로서 쉘을 설정할 수 것입니다.



WPF 응용프로그램을 위해서, 당신은 아래에 보이는 것처럼, 쉘 응용프로그램 오브젝트를 생성하고, 그것을 응용프로그래의 메인 윈도우로서 설정할 것입니다( WPF 를 위한 모듈성 퀵스타트의 코드 중 일부 ).



IniializeShell 의 기저 구현은 아무것도 수행하지 않습니다. 기저 클래스 구현을 호출하지 않는 것이 안전합니다.


모듈 카탈로그를 생성하고 구성하기



모듈 응용프로그램을 빌드하고 있다면, 모듈 카탈로그를 생성하고 빌드할 필요가 있을 것입니다. 프리즘은 견고한 IModuleCatalog 인스턴스를 사용해, 응용프로그램에 대해 이용 가능한 모듈들이 무엇인지, 어떤 모듈들이 다운로드될 수 있는지, 어디에 모듈들이 위치하는지에 대한 트랙을 유지합니다.


Bootstrapper 는 카탈로그와 CreateModuleCatalog 가상 메서드에 대한 기저 구현을 참조하기 위해 보호된 ModuleCatalog 속성을 제공합니다. 기저 구현은 새로운 ModuleCatalog 를 반환합니다; 그러나 이 메서드는, 실버라이트를 위한 MEF 를 사용한 모듈성 퀵스타트의 QuickStartBootstrapper 로부터의 코드에서 볼 수 있듯이, 다른 IModuleCatalog 인스턴스를 제공하기 위해서 재정의될 수 있습니다. 



UnityBootstrapperMefBootstrapper 클래스들에서, Run 메서드는 CreateModuleCatalog 메서드를 호출하며, 클래스들의 ModuleCatalog 속성은 그 반환값을 사용해서 설정됩니다. 만약 이 메서드를 재정의하면, 기저 클래스의 기저 구현을 호출할 필요가 없습니다. 왜냐하면 당신은 제공되는 기능을 대체할 것이기 때문이다. 모듈성에 대한 더 많은 정보를 원한다면, 도움말의 "Modular Application Development" 를 참조하십시오.


컨테이너를 생성하고 구성하기



컨테이너들은 프리즘 라이브러리를 사용해서 생성된 응용프로그램에서 핵심적인 역할을 수행합니다. 컨테이너의 최상위에서 빌드된 프라즘 라이브러리와 응용프로그램은 요청된 종속성들과 서비스들을 주입inject하기 위해서 컨테이너에 의존합니다. 컨테이너 구성 단계 동안에, 몇몇 코어 서비스들이 등록됩니다. In addition to these core services, you may have application-specific services that provide additional functionality as it relates to composition.


코어 서비스들



다음 표는 프리즘 라이브러리 내의 core non-application specific service 들을 열거합니다.



 서비스 인터페이스

설명 

 IModuleManager

 응용프로그램의 모듈들을 획득하고 초기화할 서비스들에 대한 인터페이스들을 정의합니다.

 IModuleCatalog

 응용프로그램 내의 모듈들에 대한 메타데이터를 포함합니다. 프리즘 라이브러리는 몇 가지 다양한 카탈로그들을 제공합니다.

 IModuleInitializer

 모듈들을 초기화합니다.

 IRegionManager

 영역들을 등록하고 획득하는데, 영역들은 레이아웃을 위한 비쥬얼 컨테이너들입니다.

 IEventAggregator

 발행자와 구독자 사이에 느슨하게 연결된 이벤트들의 집합입니다.

 ILoggerFacade

 로깅 메커니즘을 위한 래퍼입니다. 자신만의 로깅 메커니즘을 선택할 수 있습니다. Stock Trader Reference Implementation( Staock Trader RI ) 은 EnterpriseLibraryLoggerAdapter 클래스를 통해서 엔터프라이즈 라이브러리 로깅 응용프로그램 블락을 사용하는데, 해당 응용프로그램은 자신만의 로거를 사용하는 방법에 대한 예제로 제공됩니다. 로깅 서비스는 부트스트래퍼의 Run 메서드에 의해 컨테이너에 등록되는데, CreateLogger 메서드의 반환값을 사용합니다. 컨테이너에 또 다른 로거를 등록하는 것은 불가능합니다; 대신에 부트스트래퍼의 CreateLogger 메서드를 재정의하십시오.

 IServiceLocator

 프리즘 라이브러리가 컨테이너에 접근할 수 있도록 합니다. 만약 라이브러리를 커스터마이즈하거나 확장하려고 한다면, 이것이 유용할 것입니다.


응용프로그램 특정 서비스들



다음 표는 응용프로그램 틍정 서비스들을 열거하는데, 그것들은 Stock Trader RI 에서 사용된 것들입니다. 이는 응용프로그램이 제공할 수 있는 서비스들의 유형을 이해하는 예제로서 사용될 수 있습니다.



 Stock Traader RI 의 서비스들

 설명

 IMarketFeedService

 실시간 ( 가상의 ) 마킷 데이터를 제공합니다. PositionSummaryPresentationModel 은 이 서비스로부터 획득한 통지에 기반한 position screen 을 갱신합니다.

 IMarketHistoryService

 선택된 펀드에 대한 트렌드 라인을 디스플레이하기 위해서 사용되는 히스토리컬 마킷 데이터를 제공합니다.

 IAccountPositionService

 포트폴리오에 있는 펀드들의 리스트를 제공합니다.

 IOrderService

 제출된 판매/구입 주문들을 넣습니다.

 INewsFeedService

 선택된 펀드에 대한 뉴스 아이템들의 리스트를 제공합니다.

 IWatchListService

 새로운 관심 아이템들이 관심 리스트에 추가될 때를 다룹니다.


두 종류의 Bootstrapper 를 상속한 클래스들이 프리즘에서 이용가능한데, 그것들은 UnityBootstrapperMefBootstrapper 입니다. 서로 다른 컨테이너들을 생성하고 구성하는 것은 서로 다르게 구현된 비슷한 개념들을 포함합니다.


UnityBootstrapper 에서 컨테이너를 생성하고 구성하기



UnityBootstrapper 클래스의 CreateContainer 메서드는 단순하게 UnityContainer 를 생성하고 그것의 인스턴스를 반환합니다. 대부분의 경우에, 이 동작을 변경할 필요는 없을 것입니다; 그러나 이 메서드는 가상 메서드이며, 그러므로 유연성을 가지고 있습니다.


컨테이너가 생성되면, 아마도 응용프로그램을 위해 구성될 필요가 있습니다. UnityBootstrapper 에서 ConfigureContainer 구현은 기본적으로 몇 개의 코어 프리즘 서비스들을 다음과 같이 등록합니다.


노트 :


이 예제는 모듈이 자신의 Initialize 메서드 내에서 모듈 수준 서비스들을 등록할 때의 것입니다.




부트스트래퍼의 RegisterTypeIfMissing 메서드는 서비스가 이미 등록되었는지 여부를 판단합니다 - 그것은 두 번 등록하지 않도록 할 것입니다. 이는 구성을 통해서 당신이 기본 등록을 재정의할 수 있도록 허용합니다. 또한 기본값으로 어떤 서비스들의 등록을 해제할 수도 있습니다; 이를 위해서는, 중복정의된 Bootstrapper.Run 메서드에 false 를 넘겨서 사용하십시오. 또한 ConfigureContainer 메서드를 재정의해서 이벤트 어그리게이터와 같은 원하지 않는 서비스들을 비활성화할 수도 있습니다.


노트 :


만약 기본 등록을 해제하고 싶다면, 수동적으로 요청된 서비스들을 등록해줄 필요가 있습니다.


ConfigureContainer 의 기본 동작을 확장하려면, 단순하게 당신의 응용프로그램의 부트스트래퍼에 재정의를 추가하고, 선택적으로 기저 구현을 호출합니다. 이는 ( Unity 를 사용하는 ) WPF 를 위한 모듈성 퀵스타트로부터 가져온 QuickStartBootstraper 의 코드에 나와 있습니다. 이 구현은 기저 클래스의 구현을 호출하며, IModuleTracker 의 완전한 구현인 ModuleTracker 타입을 등록합니다. 그리고 Unity 를 사용하는 CallbackLogger 의 싱글톤 인스턴스로서 callbackLogger 를 등록합니다.



MefBootstrapper 에서 컨테이너 생성하고 구성하기



MefBootstrapper 클래스의 CreateContainer 메서드는 몇 가지 일을 수행합니다. 먼저 그것은 AssemblyCatalog CatalogExportProvider 를 생성합니다. CatalogExportProvider MefExtension 어셈블리가 여러 프리즘 타입들에 대한 기본 익스포트를 수행할 수 있도록 해 주며, 여전히 당신으로 하여금 기본 타입 등록을 재정의할 수 있게 해 줍니다. CreateContainer CatalogExportProvider 를 사용해서 CompositionContainer 의 새로운 인스턴스를 생성하고 반환합니다. 대부분의 경우에, 이 동작을 변경할 필요는 없습니다; 그러나 이 메서드는 가상 메서드이고, 그러므로 유연성을 허용합니다.


노트 :


실버라이트에서는, 보안 제약때문에, 타입을 사용해서 어셈블리를 획득하는 것이 불가능합니다. 대신에 프리즘은 Assembly.GetCllingAssembly 메서드를 사용하는 다른 메서드를 사용합니다.


컨테이너가 생성되면, 응용프로그램을 위해 구성될 필요가 있습니다. MefBootstrapper 의 ConfigureContainer 구현은 다음 예제에 나와 있는 것처럼 기본적으로 몇 개의 코어 프리즘 서비스들을 등록합니다.만약 이 메서드를 재정의한다면, 코어 프리즘 서비스들을 등록하기 위해서 기저 클래스의 구현을 호출해야 할 것인지, 당신의 구현에 이 서비스들을 제공할 것인지 주의깊게 결정해야 합니다.



노트 :


MefBootstrapper 에서, 프리즘 코어 서비스들은 싱글톤으로 컨테이너에 추가되므로, 그것들은 응용프로그램 전체에서 컨테이를 통해서 찾을 수 있습니다.


CreateContainer 메서드와 ConfigureContainer 메서드를 제공하는 것과 더불어, MefBootstrapper 는MEF 에 의해 사용되는 AggregateCatalog 를 생성하고 구성하는 두 개의 메서드들도 제공합니다. CreateAggregateCatalog 메서드는 단순히 AggregateCatalog 오브젝트를 생성하고 반환하기만 합니다. MefBootstrapper 의 다른 메서드들과 마찬가지로, CreateAggregateCatalog 는 가상 메서드이며, 필요할 때 재정의될 수 있습니다.


ConfigureAggregateCatalog 메서드는 부득이한 경우에 AggregateCatalog 에 타입 등록을 추가할 수 있도록 허용합니다. 예를 들어 실버라이트를 위한 MEF 를 사용하는 모듈성 퀵스트타의 QuickStartBootstrapper 는 명시적으로 ModuleA ModuleC AggregateCatalog 에 다음과 같이 추가합니다.



더 많은 정보



MEF, AggregateCatalog, AssemblyCatalog 에 대한 더 많은 정보를 원한다면, MSDN 의 "Managed Extensibility Framework Overview" 를 참조하십시오 : http://msdn.microsoft.com/en-us/library/dd460648.aspx


'Programming > Prism4.1' 카테고리의 다른 글

진보된 MVVM 시나리오들  (0) 2014.09.20
MVVM 패턴 구현하기  (0) 2014.09.16
모듈러 응용프로그램 개발  (0) 2014.09.13
컴포넌트 간의 종속성 관리하기  (0) 2014.09.10
왜 프리즘을 사용하는가?  (0) 2014.08.19
소개  (0) 2014.08.18
프리즘 4.1 설치  (0) 2014.08.14

도움말 번역입니다



유연하고 유지보수가 쉬운 다채로운 WPF 나 실버라이트 클라이언트 응용프로그램들을 설계하고 빌드하는 것은 도전적인 일이 될 수 있습니다. 이 섹션에서는 WPF 나 실버라이트 응용프로그램들을 빌드할 때 만날지도 모르는 일반적인 시련들의 일부에 대해서 설명하고, 프리즘이 어떤 방식으로 그러한 시련들을 다루도록 도와주는 지에 대해 설명합니다.


클라이언트 응용프로그램 개발에서의 시련들


일반적으로, 클라이언트 응용프로그램 개발자들은 매우 많은 시련들에 직면합니다. 응용프로그램 요구사항들은 계속해서 바뀝니다. 새로운 비즈니스 기회들과 시련들을 스스로 겪을 수도 있으며, 새로운 기술들이 이용 가능하게 될 수도 있고, 혹은 심지어는 개발 도중에 소비자의 피드백이 응용프로그램의 요구사항들에 중요한 영향을 미칠 수도 있습니다. 결국, 응용프로그램을 유연하고 시간이 지나도 쉽게 수정하거나 확장할 수 있도록 빌드하는 것이 중요합니다. 이러한 유형의 유연성을 위한 설계를 하는 것은 매우 어려울 수 있습니다. 그것은 응용프로그램의 개발 부분들이 서로 독립적으로 개발되고, 검사되는 것을 요구하며, 응용프로그램의 다른 부분들에 영향을 미치지 않고 별개로 수정되고 갱신되기를 원합니다.


거의 대부분의 엔터프라이즈 응용프로그램들은 충분히 복잡하며, 그것들은 한 명 이상의 개발자나 심지어는 개발자와 함께 유저 인터페이스 디자이너나 로컬라이저를 포함하는  여러 개발자들로 구성된 큰 팀을 요구합니다. 여러 개발자들이나 하위 팀들이 응용프로그램의 서로 다른 조각들 상에서 효율적으로 작업할 수 있도록 하면서 응용프로그램에 그 조각들이 통합될 때 서로 끈김없이 연결되도록 하는 응용프로그램을 설계하는 것은 매우 큰 도전입니다.


모놀리식monolithic 스타일로 응용프로그램을 설계하고 빌드하는 것은 유지보수하기 매우 어렵고 불충분한 응용프로그램으로 만들 수 있습니다. 이 경우, "모놀리식" 은 컴포넌트들이 매우 타이트하게 결합되며, 그것들 사이의 명확한 분리는 존재하지 않는 응용프로그램을 가리킵니다. 보통 이러한 방식으로 설계되고 빌드된 응용프로그램들은 개발자의 삶을 매우 어렵게 만듭니다. 그 시스템에 새로운 기능을 추가하거나 현존하는 기능을 대체하는 것은 어렵습니다. 그리고 시스템의 다른 부분들을 깨 먹지 않고 버그를 해결하기 어렵습니다. 그리고 테스트하거나 배포하기 어렵습니다. 또한 그것은 개발자들과 디자이너들이 효율적으로 협업하기 어렵게 합니다.


복합 접근법Compsite Approach


이러한 시련들을 위한 효율적인 해결방법은 응용프로그램을 여러 개의 끊어진, 느슨하게 결합된, 약간 독립적인 컴포넌트들로 나누는 것입니다. 이 컴포넌트들은 일관성있는 솔루션을 형성하기 위해서 응용프로그램 "쉘" 에 쉽게 통합될 수 있습니다. 이러한 방식으로 설계되고 빌드된 응용프로그램들은 보통 복합 응용프로그램이라고 알려져 있습니다.


복합 응용프로그램들은 많은 이점들을 가지고 있는데, 다음을 포함합니다 :


  • 그것들은 모듈들이 서로 다른 개인이나 하위 팀들에 의해 개별적으로 개발되고, 테스트되고, 배포되는 것을 허용합니다; 또한 새로운 기능들을 사용해 더욱 쉽게 수정되고 확장되는 것을 허용하며, 결국 응용프로그램이 쉽게 확장되고 유지되도록 만들어 줍니다. 심지어는 한 사람이 개발하는 프로젝트라고 할지라도 이 복합 접근법을 사용하면 더욱 검사하기 좋고 유지보수하기 좋은 응용프로그램을 생성하는데 있어서 이점을 누릴 수 있습니다.
  • 그것들은 느슨하게 결합되는 방식으로 상호작용하는 다양한 모듈들로부터 제공되는 UI 컴포넌트들로 구성된 공용 쉘을 제공합니다.이는 UI 에 새로운 기능을 추가하는데 있어 다수의 개발자들로부터 발생하는 언쟁을 줄여 주고, 공통적인 외형을 제공합니다.
  • 그것들은 로깅이나 권한과 같은 응용프로그램의 수평적 능력들과 응용프로그램에 특정한 비즈니스 기능과 같은 수직적 능력들 사이에서의 명확한 관심사 분리와 재사용성을 제공합니다. 또한 응용프로그램 컴포넌트들 사이의 종속성과 상호작용을 더욱 쉽게 관리할 수 있도록 해 줍니다.
  • 그것들은 서로 다른 개인들이나 하위 팀들이 그들의 관심사나 전문성과 관련된 특정 작업이나 기능조각에 집중할 수 있도록 함으로써, 역할 분리를 유지하는데 도움을 줍니다. 특히, 그것은 응용프로그램의 UI 와 비즈니스 로직 사이의 명확한 분리를 제공합니다 - 이는 UI 디자이너가 다채로운 사용자 경험을 생성하는데 집중할 수 있다는 것을 의미합니다.

복합 응용프로그램들은 클라이언트 응용프로그램 시나리오의 영역에 매우 잘 들어 맞습니다. 예를 들어, 그것은 복합 응용프로그램은 이질적인 백-엔드 시스템들 상에서 다채로운 엔드-유저 경험을 생성하는데 있어 이상적입니다.다음 그림은 이러한 유형의 복합 응용프로그램의 예를 보여 줍니다.




이러한 유형의 응용프로그램에서, 사용자는 다중 백-엔드 시스템들, 서비스들, 데이터 저장소들을 포괄하는 기능들 위에서 태스크-지향 포커스를 제공하는 다채롭고 유연한 사용자 경험을 제공받을 수 있습니다. 여기에서 각각의 기능들은 하나 이상의 전용 모듈들로 표현되어 있습니다. 응용프로그램 로직과 UI 사이에서의 명확한 분리는 응용프로그램이 모든 구성 모듈들 사이에서 일관적이고 차별화된 외향을 제공하도록 해 줍니다.


부가적으로 복합 응용프로그램은, 다른 컴포넌트들과 통합되어 있고 개별 팀들에 의해 자주 보수되는 UI 내에, 독립적으로 발전하는 컴포넌트들이 존재할 때 유용합니다. 다음 그림은 이러한 유형의 응용프로그램에 대한 스크린 샷을 보여 줍니다. 하이라이트된 각 영역은 UI 를 구성하는 독립적인 컴포넌트들을 의미합니다.




이 경우에, 복합 응용프로그램은 UI 가 동적으로 구성되는 것을 허용합니다. 이는 유연한 사용자 경험을 전달합니다. 예를 들어, 그것은 런타임에 응용프로그램으로 동적으로 추가될 수 있는 새로운 기능을 허용할 수 있습니다. 이는 엔드-유저 커스터마이제이션과 확장성을 가능하게 합니다.


프리즘으로 해결할 수 없는 시련들


비록 프리즘이 WPF 나 실버라이트 응용프로그램들을 빌드하면서 직면할 수 있는 많은 시련들을 해결하는데 도움을 주기는 하지만, 당신의 응용프로그램 상에서의 시나리오나 요구사항에 의존해서 직면할 수 있는 많은 다른 시련들이 존재합니다. 예를 들어 프리즘은 다음과 같은 주제들을 직접적으로 해결해줄 수 없습니다 :


  • 우연한 연결성occasional connectivity 및 데이터 동기화
  • 서비스 및 메시징 인프라스트럭쳐 설계
  • 인증authentication 및 승인authorization
  • 응용프로그램 성능
  • 응용프로그램 버전 관리
  • 에러 핸들링 및 내고장성fault tolerance


'Programming > Prism4.1' 카테고리의 다른 글

진보된 MVVM 시나리오들  (0) 2014.09.20
MVVM 패턴 구현하기  (0) 2014.09.16
모듈러 응용프로그램 개발  (0) 2014.09.13
컴포넌트 간의 종속성 관리하기  (0) 2014.09.10
프리즘 응용프로그램 초기화하기  (0) 2014.08.24
소개  (0) 2014.08.18
프리즘 4.1 설치  (0) 2014.08.14

도움말 번역입니다.




프리즘은 윈도우즈 프리젠테이션 파운데이션( WPF ) 데스크탑 응용프로그램, 실버라이트 리치 인터넷 응용프로그램( RIA ), 윈도우즈 폰 7 응용프로그램 등을 더욱 쉽게 설계하고 풍부하고 유연하고 유지보수가 쉽도록 빌드하는 것을 도와주기 위해서 설계된 가이드를 제공합니다. 관심사 분리seperation of concern, 느슨한 커플링loose coupling과 같은 중요한 구조적 설계 원칙을 포함하는 디자인 패턴을 사용함으로써, 프리즘은 당신이 느슨하게 커플링된 컴포넌트들을 사용하여 응용프로그램을 설계하고 빌드하는 것을 돕습니다. 이 컴포넌트들은 독립적으로 진화할 수 있지만, 쉽고 끊김없이 전체 응용프로그램으로 통합될 수도 있습니다. 이러한 유형의 응용프로그램들은 복합 응용프로그램composite appliccation이라고 알려져 있습니다.


노트

프리즘은 WPF 와 실버라이트를 위한 복합 응용프로그램 가이드라고 공식적으로 알려진 가이드의 코드명입니다. 간결함과 사용자 요구에 의해, 이 가이드는 간단하게 프리즘이라고 불립니다.


프리즘은 보통 다중 스크린, 풍부한 유저 상호작용, 데이터 가시화를 형성하며, 중요한 프리젠테이션과 비즈니스 로직을 포함하는 WPF 혹은 실버라이트 응용프로그램 빌드하고 있는 소프트웨어 개발자드를 위해서 만들어졌습니다. 이 응용프로그램들은 보통 레이어 구조를 사용하는 다중 백엔드 시스템들과 상호작용하며, 물리적으로 다중 티어 사이에서 배치되어 있을 수 있습니다. 그 응용프로그램들은 새로운 요구들과 비즈니스 기회들에 응답해 그것의 생명주기가 끝나면 크게 진화되기를 기대받습니다. 짧게 말하자면, 이 응용프로그램들은 "지속적이며" "변화를 반영합니다". 이러한 특징들을 만족시키지 않는 응용프로그램들은 프리즘을 사용해서 이득을 보기 힘들 것입니다.


프리즘은 참조 구현들, 퀵스타트, 재사용 가능한 라이브러리 코드( 프리즘 라이브러리 ), 방대한 문서를 포함합니다. 이 버전의 프리즘은 마이크로 소프트 닷넷 4.0 과 실버라이트 4 를 대상으로 하며, 모델-뷰-뷰모델( MVVM ) 패턴, 네이게이션, 관리되는 확장 가능성 프레임워크Managed Extensibility Framework( MEF ) 등과 관련된 새로운 가이드를 포함합니다. 프리즘은 ( WPF 를 포함하는 ) 닷넷 프레임워크 4.0 과 실버라이트 상에서 빌드되기 때문에, 이 기술들사이의 유사성은 프리즘을 평가하고 받아들이는데 도움이 됩니다.


명심할 것은, 프리즘이 배우기 어렵지는 않지만, 개발자들은 그들에게는 생소할 만한 패턴 및 경험들을 받아들일 준비와 의지를 가져야만 합니다. 관리에 대한 이해와 책임감이 중요하며, 프로젝트 마감은 이 패턴들과 경험들을 배우는데 필요한 시간 투자를 감안해야만 합니다.

'Programming > Prism4.1' 카테고리의 다른 글

진보된 MVVM 시나리오들  (0) 2014.09.20
MVVM 패턴 구현하기  (0) 2014.09.16
모듈러 응용프로그램 개발  (0) 2014.09.13
컴포넌트 간의 종속성 관리하기  (0) 2014.09.10
프리즘 응용프로그램 초기화하기  (0) 2014.08.24
왜 프리즘을 사용하는가?  (0) 2014.08.19
프리즘 4.1 설치  (0) 2014.08.14

요구 사항



프리즘 4.1 을 사용하기 위해서는 다음의 요구사항을 만족해야 한다.



실버라이트 관련 도구를 받을 때 주의할 사항은 자신의 비쥬얼 스튜디오의 언어팩에 맞는 언어를 선택해서 받아야 한다는 것이다.


설치하기


Prism4.1_Source.EXE 파일을 받으면 그냥 관리자 권한으로 실행하면 된다. 그러면 압축을 풀 폴더를 지정하라고 하는데, 반드시 폴더를 생성한 후에 지정하기 바란다. 아니면 선택한 폴더에 그냥 풀려 버린다. 필자는 C 에다가 그냥 풀었다가 그냥 C 에 다 풀리는 바람에 그것을 원하는 폴더로 다시 모으느라고 삽질을 해야 했다.


등록하기


프리즘을 비쥬얼 스튜디오에 등록할 수도 있고 등록하지 않을 수도 있다. 등록하게 되면 프로젝트에서 프리즘 라이브러리를 참조하기 편해진다. 등록하면 비쥬얼 스튜디오에서 "참조 추가" 를 누르면 나오는 다이얼로그에서 라이브러리들을 쉽게 찾을 수 있다.



프리즘 라이브러리를 등록하려면, 프리즘이 설치된 폴더의 "RegisterPrismBinaries.bat" 를 더블 클릭해 주는 것만으로 끝이다.


만약 프리즘 라이브러리가 여러 번 등록되면 마지막에 등록된 것을 사용하게 된다.



참고



설치에 대한 더 자세한 내용을 알고 싶다면 프리즘 라이브러리 설치 후에, 해당 폴더의 "Prism4.chm" 을 실행해 "Prism 4.0 Readme" 토픽을 읽어 보기 바란다.

'Programming > Prism4.1' 카테고리의 다른 글

진보된 MVVM 시나리오들  (0) 2014.09.20
MVVM 패턴 구현하기  (0) 2014.09.16
모듈러 응용프로그램 개발  (0) 2014.09.13
컴포넌트 간의 종속성 관리하기  (0) 2014.09.10
프리즘 응용프로그램 초기화하기  (0) 2014.08.24
왜 프리즘을 사용하는가?  (0) 2014.08.19
소개  (0) 2014.08.18

+ Recent posts