Prism 4.0 - Chapter 1. Introduction
Prism 4.0 도움말을 번역한 글입니다. 중간 중간 오역도 (당연히) 있을 수 있으며, msdn에 번역된 기사에서 나온 표현을 최대한 쓰려고 노력했습니다(만 잘 안되네요). 이상하다 싶으면 반드시 Prism 4.0 도움말에서 원문을 읽어보세요. 시간 날 때 마다 틈틈이 번역해서 올리겠습니다. – Spencer
시작하며
Prism은 풍부하고, 유연한, 그리고 유지 보수가 쉬운 WPF 데스크톱 응용이나 실버라이트 RIAs, Windows Phone 7 응용을 쉽게 디자인하고 개발 할 수 있는 가이드라인을 제공합니다. ‘관심자의 분리(seperation of concerns’나 ‘낮은 결합도(loose coupling)’과 같은 중요한 아키텍처적 디자인 원칙을 포함하는 디자인 패턴을 사용하여, 독립적이면서도 전체 응용 프로그램에 쉽고 이음새 없이 통합할 수 있는 낮은 결합도의 컴포넌트를 설계하고 개발하는 것을 도와줍니다.
Note : Prism은 공식으로 ‘The Composite Application Guidance for WPF and Silverlight’로 알려진 지침의 코드 네임입니다.고객들의 요구 및 간결성을 위해서 지금은 간단하고 Prism으로 부릅니다.
Prism은 다중 스크린을 사용하거나, 사용자 인터렉션이 많거나, 중요한 표현 계층 및 비즈니스 로직을 포함한 WPF 혹은 Silverlight 응용을 개발하는 소프트웨어 개발자를 위해 고안되었습니다. 이러한 보통 다중 백엔드(back-end) 시스템이나 서비스, 계층적 아키텍처와 상호작용하는 이러한 응용들은 여러 계층을 통계 물리적으로 배포될 수 있다. 새로운 요구 사항이나 비즈니스 기회를 통해 응용의 생명주기 동안 상당히 변경된다. 짧게 말해, 이러한 응용은 튼튼하게 만들어져야(built to last)하며 변경이 쉬워야 합니다.(built for change). 이러한 특징을 가지지 않는 응용은 Prism을 사용하는데 아무런 이득이 없습니다.
Prism은 Reference Implementations와 QuickStarts, 재사용 가능한 라이브러리 코드(the Prism Library), 광범위한 문서가 포함되어 있습니다. 이 Prism 버전은 Microsoft .NET Framwork 4.0과 Silverlight 4, 그리고 Model-View-ViewModel(MVVM) 패턴과 Navigation, Managed Extensibility Framwork(MEF)을 포함한 새 지침을 포함하고 있습니다. Prism은 .NET Framwork 4.0(WPF 포함), Silverlight 4 상에서 개발되었기 때문에, 이러한 기술들에 익숙하다면 Prism을 평가하고 적용하는데 도움이 될 것입니다.
Prism은 배우기 어렵지 않으나, 개발자는 반드시 처음 마주할 패턴과 관례(practices)를 받아드릴 준비가 되어야 합니다. 관리에 대한 이해와 약속은 중요하며, 프로젝트 기한은 반드시 이러한 패턴과 관례를 익히기 위한 선행시간이 포함되어야 합니다.(It should be noted that while Prism is not difficult to learn, developers must be ready and willing to embrace patterns and practices that may be new to them. Management understanding and commitment is crucial, and the project deadline must accommodate an investment of time up front for learning these patterns and practices.)
왜 Prism을 사용하는가?
유연하고 유지보수가 쉬운 WPF/Silverlight 클라이언트 프로그램을 디자인하고 개발하는 것은 도전적입니다. 이 섹션에서는 WPF/Silverlight 클라이언트 프로그램을 개발할 때 마주칠 일반적인 문제들을 설명하고, Prism에서는 어떻게 이러한 문제를 다루는지 설명하겠습니다.
클라이언트 프로그램 개발 문제
보통, 클라이언트 프로그램 개발자들은 몇몇 상당히 약간의 문제에 부딪칩니다. 프로그램 요구사항은 매번 바뀝니다. 새 비즈니스 기회와 과제는 그 자체로서 혹은 새로운 사용 가능한 기술 또는 개발 기간 중에 들어오는 고객의 요구사항으로 인해 프로그램의 요구사항이 변경됩니다. 그러므로 개발 기간 동안 유연하면서도 쉽게 수정 가능한 프로그램을 개발하는 것이 중요합니다. 이러한 유형의 유연함을 디자인하는 것은 매우 어렵습니다. 프로그램의 다른 부분에 영향을 주지 않으면서, 프로그램의 각각의 부분이 독립적으로 개발되고 테스트 될 수 있는 아키텍처가 필요합니다.
대부분의 엔터프라이즈 어플리케이션은 한 명 이상의 개발자, 심지어 UI 디자이너나 지역화 담당자가 있는 큰 팀이 필요할 정도의 복잡성을 가지고 있습니다. 여러 개발자나 서브 팀들이 독립적으로 프로그램의 다른 부분을 효율적으로 개발하면서도, 프로그램에 통합될 때 이음새 없이 잘 동작하는 것을 보장할 수 있는 디자인을 결정하는 것은 매우 중요한 과제입니다.
하나로 집적된(monolithic) 형태로 디자인하고 개발하는 응용들은 유지보수하기 매우 어렵고 비효율적입니다. 여기서 “집적된(monolithic)”은 컴포넌트들이 매우 밀접하게 결합되어 있고, 각각이 명확히 분리되지 않는 프로그램을 의미합니다. 보통, 이렇게 디자인되고 개발된 프로그램은 개발자의 삶을 힘들게 합니다. 또한 새 기능을 넣거나, 기존의 기능을 대체하는 것이 어려우며, 버그를 발견하기 어려우며, 테스트하거나 배포하는 것이 어렵습니다. 또한 개발자와 디자이너가 함께 효율적으로 일할 수 있는데도 영향을 줍니다.
Composite 접근
이러한 문제점에 대한 효율적인 해결책은 프로그램을 일관된 해결책의 형태를 지닌 프로그램 “쉘(shell)” 형태로 쉽게 통합할 수 있는 약간은 독립적이면서 느슨하게 결합된 몇 개의 컴포넌트로 분리하는 것입니다. 이러한 방법으로 디자인되고 개발된 프로그램은 흔히 복합 응용 프로그램(composite application)이라고 불립니다.
복합 응용 프로그램은 다음과 같은 장점을 가집니다.
- 각각의 모듈은 서로 다른 사람이나 서브 팀이 개별적으로 개발하고 테스트하고 배포될 수 있습니다. 좀 더 쉽게 새 기능들이 수정되거나 확장될 수 있기 때문에 응용 프로그램은 좀더 쉽게 확장되거나 유지될 수 있습니다. composite 접근법을 사용하면 심지어 한 명이 진행하는 프로젝트에서도 보다 테스트 가능하며 유지보스가 가능한 응용프로그램을 만드는데 도움이 됩니다.
- 느슨하게 결합된 방법으로 상호작용하는 다양한 모듈들이 제공하는 UI 컴포넌트들이 구성된 쉘을 사용할 수 있습니다. 이는 UI에 새 기능을 추가하려는 여러 개발자들 사이에서 발생하는 논쟁을 줄일 수 있으며, 일관된 형태를 가질 수 있도록 지원합니다.
- 로깅이나 인증과 같은 응용 프로그램의 수평적 기능, 응용 프로그램의 구체적인 비즈니스 기능과 같은 수직적 기능 사이의 관심사 분리가 깔끔하게 이루어 질 수 있으며, 재사용 가능하게 지원합니다. 또한 좀 더 쉽게 응용 프로그램 사이의 상호작용과 종속성들을 관리 할 수 있도록 지원합니다.
- 다른 개발자 혹은 서브 팀들이 특정 과업 혹은 관심이나 전문성에 따른 기능의 분화에 집중 할 수 있도록 하여, 역할 분리를 유지하는데 도움이 됩니다. 특히, 응용프로그램의 UI와 비즈니스 로직이 깔끔하기 분리될 수 있도록 지원합니다.
복합 응용 프로그램은 전반적인 클라이언트 응용 프로그램 시나리오에 적합합니다. 예를 들어, 복합 응용 프로그램은 이질적인 백엔드 시스템 상에서의 풍부한 UX를 개발하는데 이상적인 방법입니다.
이러한 형태의 응용 프로그램은, 하나 이상의 전용 모듈로 표현되는 여러 데이터 보관, 서비스, 백엔드 시스템을 바탕으로 확장된 기능 상에서 과업에 초점을 둔 풍부하고 유연한 UX를 사용자에게 제공할 수 있습니다. 응용 프로그램 로직과 UI 간의 깔끔한 분리는 응용프로그램이 모든 구성 모듈 전체에 걸쳐 일관이면서도 구분된 외형을 제공할 수 있습니다.
게다가, 복합 응용 프로그램은 이따금 서로 다른 팀에 의해서 유지되거나 서로에서 밀접하게 통합된 UI 상의 컴포넌트가 독립적으로 개발될 때 유용합니다. 강조된 각각의 영역은 UI 상에 구성된 독립 컴포넌트를 의미합니다.
복합 응용 프로그램으로 구현된 주식 거래 참조 프로그램
이 경우에서, 복합 응용프로그램은 UI가 동적으로 결합될 수 있도록 지원한다. 이는 유연한 UX를 가져다 준다. 예를 들어, 실행 중에 응용 프로그램에 새 기능을 동적으로 붙일 수 있으며, 이는 풍부한 사용자화와 확장성(extensibility)을 가능케 한다.
Prism이 다루지 않는 문제
WPF/Silverlight를 개발하는데 직면하는 여러 문제를 Prism이 도와주지만, 응용 프로그램의 시나리오나 요구사항에 따라 다른 다양한 문제에 직면할 것입니다. 예를 들어 다음에 나오는 주제는 직접적으로 다루지 않습니다.
- Occasional connectivity와 데이터 동기화
- 서비스와 메시지 기반 디자인
- 인증과 인가
- 응용프로그램 성능
- 응용 프로그램 버전차별전략(Versioning)
- 에러 처리 및 장애 허용 능력(fault tolerance)
제외: Getting Started with Prism
해당 섹션은 설치 및 설치 파일 설명이기 때문에 건너뜁니다. 궁금하시면 Prism 4.0 도움말을 참조하세요.
Prism의 개요
Prism 디자인 목표
Prism은 풍부하고 유연하고 유지가 쉬운 WPF/Silverlight 응용 프로그램 디자인과 개발을 돕기 위해 고안되었습니다. Prism 라이브러리는 “관심사 분리(separation of concerns)”나 낮은 결합도와 같은 중요한 아키텍처적 디자인 원칙을 포함하는 디자인 패턴을 구현하였습니다. Prism 라이브러리가 제공하는 디자인 패턴과 기능을 사용하면, 개발자는 전체 응용 프로그램에 쉽고 이음새 없이 통합할 수 있으면서도 독립적으로 개발되는 낮은 결합도의 컴포넌트를 디자인하고 개발할 수 있습니다.
Prism은 핵심 아키텍처 디자인 원칙인 관심사의 분리와 낮은 결합도를 바탕으로 디자인 되었습니다. 이는 다음의 장점을 가지게 됩니다:
- 재사용(Reuse). Prism은 컴포넌트나 서비스가 하나 이상의 응용 프로그램에 쉽게 개발, 테스트, 통합 될 수 있는 컴포넌트를 사용하여 재사용을 가능하게 합니다. 재사용은 종속성 주입(dependency injection)을 통해 실행 중에 쉽게 발견하고 통합될 수 있는 단위 테스트 컴포넌트를 재사용을 통해 컴포넌트 레벨에서 이룰 수 있으며, 응용 프로그램 레벨에서는 응용 프로그램 전반에서 사용할 수 있는 응용프로그램 레벨의 기능을 캡슐화한 모듈의 재사용을 통해 이룰 수 있습니다.
- 확장성(Extensibility). Prism은 컴포넌트 종속성 관리, 실행 중 모듈 교체, 독립적으로 배포될 수 있는 모듈들로 분화를 통해 쉽게 확장 가능한 응용 프로그램을 만들 수 있도록 지원합니다. Prism 라이브러리의 많은 컴포넌트 또한 확장되고 교체될 수 있습니다.
- 유연성(Flexibility). Prism은 개발하고 통합되는 새로운 기능들이 쉽게 변경될 수 있도록 지원하여 유연한 응용 프로그램을 개발 할 수 있도록 도와줍니다. Psirm은 응용 프로그램을 대부분 원하는 방향으로 배포하고 소비할 수 있도록 지원하여, WPF/Silverlight 응용 프로그램이 일반적인 서비스나 컴포넌트를 활용해 개발 할 수 있도록 지원합니다.
- 팀 단위의 개발(Team Development). Prism은 각기 다른 팀에서 개발하고 심지어 독립적으로 응용 프로그램의 각각의 부분을 배포하는 것을 지원합니다. Prism은 팀 간에 종속성을 최소화 시켜 각각의 기능 영역(UI 디자이너-비즈니스 로직 개발-핵심 인프라 개발자), 비즈니스 레벨의 기능 영역(프로필, 판매, 장바구니, 배송)에 집중할 수 있게 합니다
- 품질(Quality). Prism은 이미 검증된 일반적인 서비스나 컴포넌트 활용 또는 개발팀이 테스트를 가능하게 하여 품질을 향상시킬 수 있습니다. 덧붙여, 이미 검증된 디자인 패턴, 디자인 패턴을 아우르는 지침을 제공하여, Prism은 개발팀이 인프라의 구현 및 테스트 대신 응용 프로그램의 요구조건에 집중할 수 있도록 합니다.
응용 프로그램의 시나리오나 요구사항에 맞추어 Prism의 기능과 디자인 패턴을 사용할 수 있습니다. Prism은 중요한 구조적 변경 없이 당신의 특정 응용 프로그램에 맞추어 디자인 패턴이나 기능을 점증적으로 적용할 수 있도록 디자인되어 있습니다.
마지막으로, 소프트웨어 테스팅은 개발 활동 중에 제일 염두 해야 할 사항이며, 개발 프로세스에 엄격하게(tightly) 통합되어야 하기 때문에, Prism은 당신이 쉽게 테스트 할 수 있는 응용 프로그램을 디자인하고 개발 할 수 있도록, 다양한 형태의 소프트웨어 테스팅을 광범위하게 지원합니다. Prism은 애초에 테스팅을 고려해 개발 했습니다. Microsoft 보안 표준을 만족하는 여러 엄격한 품질 검증을 만족하며, 이는 여러 OS, 다양한 버전의 Visual Studio, 다양한 프로그래밍 언어에서 정상적으로 동작합니다. 단위 테스트 또한 각각의 check-in 후 진행되었습니다. Prism은 아래에 나열된 품질 검증에 맞추어 테스트 했습니다.
테스트 | 설명 |
Acceptance Testing | 응용 프로그램의 기능을 사용자 시나리오에 맞추어 검증합니다. 테스트는 수동 혹은 자동으로 이루어집니다. |
Application Building Exercises | Team members build applications consuming the deliverable software |
Black Box Testing | 사용자 관점에서 이루어지는 수동 Acceptance tests. |
Cross Browser Testing | 여러 브라우저에서 이루어지는 자동 테스트 |
Cross Platform Testing | 여러 플랫폼에서 이루어지는 자동 테스트 |
Globalization Testing | 여러 언어에서 이루어지는 자동 테스트 |
Performance Testing | 부하 상태에서 시스템의 특정 기능이 얼마나 빨리 수행되는지 측정 (Measures how fast a particular aspect of a system performs under-load.) |
Security Review | 쓰레드 모델, 공격 요소 식별, 보안 분석 도구를 통해 코드 실행을 포함한 내부 Microsoft 보안 감사 표준 |
Stress Testing | 메모리 누수나 쓰레드 이슈를 검출하기 위한 과부하 상태에서 시스템의 안정성 측정 |
White Box Testing | 표준 준수 및 구조, 전체 아키텍처에 어떻게 배치되는지를 소스 코드 레벨에서 검증 |
Prism 라이브러리의 소스코드는 아래 표에 나와있듯이, 단위 테스트/UI 자동화 테스트까지 포함되어 있습니다. 당신은 이러한 소스를 교육적인 자료나 Prism 라이브러리를 테스트하는데 사용하실 수 있습니다. 테스트 코드는 수정/재 컴파일/테스트 배포하실 수 있습니다.
Test | Description |
UI 자동화 테스트 | 제한된 범위의 Acceptance Testing; 사용자 관점에서 응용 프로그램 검증 |
단위 테스트 | 구현된 클래스의 검증 |
Prism의 중요 개념
Prism이 제공하는 기능과 디자인 패턴은 당신이 디자인 패턴이나 복합 응용 프로그램 개발에 익숙하지 않으면 어려울 수 있습니다. 이번 절에서는 Prism에 깔려있는 중요한 개념의 대해 간략히 살펴보고, 이 문서나 코드에서 사용하는 단어에 대한 정의도 함께 알아보겠습니다.
- 모듈. 모듈은 기능의 집합으로서 독립적으로 개발/테스트/배포가 가능합니다. 다양한 상황에서, 모듈은 다른 팀에서 개발되고 유지됩니다. 일반적인 Prism 응용 프로그램은 여러 모듈로 구성됩니다. 모듈은 비즈니스와 관계된 기능으로 표현되며, 기능을 구현하기 위한 모든 View, Service, Data Model을 캡슐화 합니다. 모듈은 여러 응용프로그램에서 재사용 가능한 범용 응용 프로그램 기반이나 서비스(예를 들어, 로깅이나 예외 관리 서비스)를 캡슐화 하기도 합니다.
- 모듈 카탈로그. 복합 응용 프로그램에서, 실행 응용 프로그램은 모듈을 실행 시에 반드시 발견하고 로딩해야 합니다. Prism에서 모듈 카탈로그는 어떤 모듈을, 언제, 어떤 순서로 로딩할 것인지를 기술하기 위해 사용합니다. ModuleManager와 Module Loader 컴포넌트가 원격에 있는 모듈을 다운 받거나 응용 프로그램 도메인에 있는 모듈을 불러오거나 초기화 하기 위해서 모듈 카탈로그를 사용합니다. Prism은 프로그래밍적인 코드를 사용하거나 선언형태의 XAML, 또는 설정 파일을 통한 여러 방법으로 모듈 카탈로그를 구성할 수 있습니다. 원하면 당신만의 모듈 카탈로그를 만들 수 있습니다.
- Shell. The shell is the host application into which modules are loaded. The shell defines the overall layout and structure of the application, but it is typically unaware of the exact modules that it will host. It usually implements common application services and infrastructure, but most of the application's functionality and content is implemented within the modules. The shell also provides the top-level window or visual element that will then host the different UI components provided by the loaded modules.
- Views. Views are UI controls that encapsulate the UI for a particular feature or functional area of the application. Views are used in conjunction with the MVVM or Model-View-Presenter (MVP) patterns, which are used to provide a clean separation of concerns between the UI and the application's presentation logic and data. Views are used to encapsulate the UI and define user interaction behavior, thereby allowing the view to be updated or replaced independently of the underlying application functionality. Views use data binding to interact with view model and presenter classes.
- View models and presenters. View models are classes that encapsulate the application's presentation logic and state. They are part of the MVVM pattern. View models encapsulate much of the application's functionality. Presenters are similar to view models in that they encapsulate the presentation logic and state. They are used as part of the MVP pattern. Both view models and presenters define properties, commands, and events, to which controls in the view can data-bind.
- Models. Model classes encapsulate the application data and business logic. They are used as part of the MVVM or MVP patterns. Models encapsulate data and any associated validation and business rules to ensure data consistency and integrity.
- Commands. Commands are used to encapsulate application functionality in a way that allows them to be defined and tested independently of the application's UI. They can be defined as command objects or as command methods in the view model or presenter. Prism provides the DelegateCommand class and the CompositeCommand class. The latter is used to represent a collection of commands which are all invoked together.
- Regions. Regions are logical placeholders defined within the application's UI (in the shell or within views) into which views are displayed. Regions allow the layout of the application's UI to be updated without requiring changes to the application logic. Many common controls can be used as a region, allowing views to be automatically displayed within controls, such as a ContentControl, ItemsControl, ListBox, or TabControl. Views can be displayed within a region programmatically or automatically. Prism also provides support for implementing navigation with regions. Regions can be located by other components through the RegionManager component, which uses RegionAdapter and RegionBehavior components to coordinate the display of views within specific regions.
- Navigation. Navigation is defined as the process by which the application coordinates changes to its UI as a result of the user's interaction with the application or internal application state changes. Prism supports two styles of navigation: state-based navigation, where the state of an existing view is updated to implement simple navigation scenarios, and view-switching navigation, where new views are created and old views replaced within the application's UI. View-switching navigation uses a Uniform Resource Identifier (URI)–based navigation mechanism in conjunction with Prism regions to allow flexible navigation schemes to be implemented.
- EventAggregator. Components in a composite application often need to communicate with other components and services in the application in a loosely coupled way. To support this, Prism provides the EventAggregator component, which implements a pub-sub event mechanism, thereby allowing components to publish events and other components to subscribe to those events without either of them requiring a reference to the other. The EventAggregator is often used to allow components defined in different modules to communicate with each other.
- Dependency injection container. The Dependency Injection (DI) pattern is used throughout Prism to allow the dependencies between components to be managed. Dependency injection allows component dependencies to be fulfilled at run time, and it supports extensibility and testability. Prism is designed to work with Unity or MEF, or with any other dependency injection containers via the ServiceLocator.
- Services. Services are components that encapsulate non-UI related functionality, such as logging, exception management, and data access. Services can be defined by the application or within a module. Services are often registered with the dependency injection container so that they can be located or constructed as required and used by other components that depend on them.
- Controllers. Controllers are classes that are used to coordinate the construction and initialization of views that are to be displayed in a region within the application's UI. Controllers encapsulate the presentation logic that determines which views are to be displayed. The controller will use Prism's view-switching navigation mechanism, which provides an extensible URI-based navigation mechanism to coordinate the construction and placement of views within regions. The Application Controller pattern defines an abstraction that maps to this responsibility.
- Bootstrapper. The Bootstrapper component is used by the application to initialize the various Prism components and services. It is used to initialize the dependency injection container to register any application-level components and services with it. It is also used to configure and initialize the module catalog and the shell's view and view model or presenter.
- Multi-targeting. Prism supports the development of applications that can target both WPF and Silverlight. By adopting a separated presentation pattern, such as the MVVM or MVP patterns, you can separate the UI of your application from its presentation and business logic. View model, presenter, and model classes can be reused in both WPF and Silverlight versions of the same application. WPF-specific and Silverlight-specific views can then be defined in a way that encapsulates the UI for each.
Prism is designed so that you can use any of the preceding capabilities and design patterns individually, or all together, depending on your requirements and your application scenario. You can use the MVVM pattern, modularity, regions, commands, or events in any combination without having to adopt all of them. Of course, if you want to take full advantage of the benefits that separation of concerns and loose coupling offers, you will typically use many of Prism's capabilities and design patterns in conjunction with each other. The following illustration shows a typical Prism application architecture and shows how all the various capabilities of Prism can work together within a multi-module composite application.
Typical composite application architecture with the Prism Library
Most Prism applications consist of a shell application that defines regions for displaying top-level views and shared services that can be accessed by the loaded modules. The shell defines a suitable catalog to specify which modules are to be loaded at startup time or on-demand, as appropriate. A dependency injection container is also defined, which allows component dependencies to be fulfilled at run time. Shared services and components are registered with the container by the Bootstrapper when the application starts.
Individual modules encapsulate a portion of the overall application's functionality and, using a separated presentation pattern such as MVVM, define views, view models, models, and service components. When the modules are loaded, views defined within the modules are displayed within the regions defined by the shell. After initialization completes, the user then navigates within the application using state-based or view-switching navigation to coordinate the visual update or display of new views within the application's regions.
Using Prism
Now that you've seen the major capabilities and design patterns that Prism supports, it's time to see how easily you can start to use Prism when developing a new application. This section provides an overview of the first few steps required to create a basic Prism application. You can extend this basic application to leverage the additional capabilities and design patterns provided by Prism, as required by your scenario.
Note:
Although the Prism Library can be easily used to build new composite WPF or Silverlight applications (or applications that target both), you can also use Prism with existing applications that want to take advantage of one or more Prism capabilities or design patterns.
A Prism application typically consists of a shell project and multiple module projects. The following illustration shows common activities needed when developing a composite application using the Prism Library.
Activities for creating a composite application
A typical Prism application leverages most or all of the Prism capabilities and design patterns described earlier to be able to fully realize the benefits of the loose coupling and separation of concerns architectural design principles. However, for this example, the steps required to create a basic Prism application that consists of a single module that defines a single view are described.
Note:
Prism Library References
Most of your projects will need to reference the Prism Library assemblies. Prism provides signed binary versions of the Prism Library assemblies and a script that allows you to register them with Visual Studio so that you can use the Visual Studio Add References dialog box to add references to them. If you decide to not register the binaries, you will need to manually add references to the Prism Library binaries to your projects. You can also include the Prism Library projects in your solution and then use project references to them. The latter has the advantage of being able to use features like Go To Definition to step down into the Prism types, as well as being able to build and sign the Prism Library assemblies with your own strong name or certificate as part of your build process.
Define the Shell
The application shell provides the basic layout for the application. This layout is defined using regions that modules can use to place views. Views, like shells, can use regions to define discoverable areas that content can be added to, as shown in the following illustration. Shells typically set the appearance for the entire application and contain the styles that are used throughout the application.
Shells, views, and regions
Create the Bootstrapper
The bootstrapper is the glue that connects the application with the Prism Library services and the Unity or MEF containers. Each application creates an application-specific bootstrapper, which typically inherits from either UnityBootstrapper or MefBootstrapper, as shown in the following illustration. You will need to decide the approach you want to use to populate the module catalog. Minimally, each application will provide a module catalog and a shell.
By default, the bootstrapper logs events using the .NET Framework Trace class. Most applications will want to supply their own logging services, such as Enterprise Library logging. Applications can supply their logging service in their bootstrapper.
By default, the UnityBootstrapper and MefBootstrapper enable the Prism Library services. These can be disabled or replaced in your application-specific bootstrapper.
Diagram demonstrating connecting to the Prism Library
Create the Module
The module contains the views and services specific to a piece of the application's functionality. Frequently, these are contained in separate assemblies and developed by separate teams. A module is denoted by a class that implements the IModule interface. These modules, during initialization, register their views and services and may add one or more views to the shell. Depending on your module discovery approach, you may need to apply attributes to your module classes or define dependencies between your modules.
Add a Module View to the Shell
Modules take advantage of the shell's regions for placing content. During initialization, modules use the RegionManager to locate regions in the shell and add one or more views to those regions or register one or more view types to be created within those regions. The RegionManager is responsible for keeping track of regions throughout the application and is a core service initialized from the bootstrapper.
The remaining chapters in this guide provide details about Prism key concepts.