Prism WPF の View Composition を学ぶ

[PRISM LIBRARY の Documentation から WPF の View Composition](https://prismlibrary.com/docs/wpf/view-composition.html) の箇所を学んでみます。

そのまんまの翻訳ですが、メモとして。
日本語がへんなところは英語に戻ってそれなりに理解。。。

#Prism Library for WPFを使用したユーザーインターフェイスの作成

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/7074a144-ecd8-922b-8258-fd02df0b27fa.png)

```
Composing the User Interface Using the Prism Library for WPF
```
Prism Library for WPFを使用したユーザーインターフェイスの作成

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/d5a33ed7-fa61-bee1-b428-e2aee14dafb9.png)

```
A composite application user interface (UI) is composed from loosely coupled visual components known as views that are typically contained in the application modules, but they do not need to be.
If you divide your application into modules, you need some way to loosely compose the UI, but you might choose to use this approach even if the views are not in modules.
To the user, the application presents a seamless user experience and delivers a fully integrated application.
```
複合アプリケーションユーザーインターフェイス（UI）は、ビューと呼ばれる疎結合されたビジュアルコンポーネントから構成されます。
これらは通常、アプリケーションモジュールに含まれていますが、そうである必要はありません。
アプリケーションをモジュールに分割する場合、UIを大まかに構成する何らかの方法が必要ですが、ビューがモジュール内にない場合でも、このアプローチを使用することを選択する場合があります。
ユーザーにとって、アプリケーションはシームレスなユーザーエクスペリエンスを提供し、完全に統合されたアプリケーションを提供します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/212930da-22b4-61d6-5e09-d390c159a1d5.png)

```
To compose your UI, you need an architecture that allows you to create a layout composed of loosely coupled visual elements generated at run time.
Additionally, the architecture should provide strategies for these visual elements to communicate in a loosely coupled fashion.
```
UIを構成するには、実行時に生成される疎結合された視覚要素で構成されるレイアウトを作成できるアーキテクチャが必要です。
さらに、アーキテクチャは、これらの視覚要素が疎結合の方法で通信するための戦略を提供する必要があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/10faaa20-0acd-6bdc-29ab-66a05d0a105e.png)

```
An application UI can be built by using one of the following paradigms:

・All required controls for a form are contained in a single Extensible Application Markup Language (XAML) file, composing the form at design time.

・Logical areas of the form are separated into distinct parts, typically user controls.
The parts are referenced by the form, and the form is composed at design time.

・Logical areas of the form are separated into distinct parts, typically user controls.
The parts are unknown to the form and are dynamically added to the form at run time.
Applications that use this methodology are known as composite applications using UI composition patterns.
```
アプリケーションUIは、次のいずれかのパラダイムを使用して構築できます。

・フォームに必要なすべてのコントロールは、単一のXAML（Extensible Application Markup Language）ファイルに含まれ、設計時にフォームを構成します。

・フォームの論理領域は、通常ユーザーコントロールである別個の部分に分けられます。
パーツはフォームによって参照され、フォームは設計時に構成されます。

・フォームの論理領域は、通常ユーザーコントロールである別個の部分に分けられます。
パーツはフォームには認識されず、実行時にフォームに動的に追加されます。
この方法論を使用するアプリケーションは、UI構成パターンを使用する複合アプリケーションと呼ばれます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/90a05b17-28c3-a371-33bb-8d7fe0f26737.png)

```
Below is a picture of an app.
It is composed by loading multiple views that come from different modules into regions exposed by the shell, as shown in the following illustration.
```
以下はアプリの写真です。
次の図に示すように、異なるモジュールからの複数のビューをシェルによって公開された領域にロードすることによって構成されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/9c19d821-632c-3d54-0ec0-4eed67546b2a.png)

##UI Layout Concepts

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/d88cc19a-64c1-e3b4-e494-356133112e15.png)

```
The shell is typically the main application window and it is comprised of regions.
Regions are mostly contained within ContentControl's, ItemControl's and TabControl's, and the shell has no knowledge of what is implemented in the region.
Inside the region are views.
The view is the implementation of a specific portion of the UI and is decoupled from other parts of the application.

The following sections introduce the high-level core concepts for composite application development.
```
シェルは通常、メインアプリケーションウィンドウであり、リージョンで構成されています。
リージョンは主にContentControl、ItemControl、TabControlに含まれており、シェルはリージョンに何が実装されているかを認識していません。
地域の内部にはビューがあります。
ビューは、UIの特定の部分の実装であり、アプリケーションの他の部分から切り離されています。

次のセクションでは、複合アプリケーション開発の高レベルなコアコンセプトを紹介します。

###Shell
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/52a1a5c2-bdd1-129a-866d-c4dda7a83d7f.png)

```
The shell is the application root object that contains the primary UI content.
In a Windows Presentation Foundation (WPF) application, the shell is the Window object.

The shell plays the role of a master page providing the layout structure for the application.
The shell contains one or more named regions where modules can specify the views that will appear.
It can also define certain top-level UI elements, such as the background, main menu, and toolbar.
```
シェルは、プライマリUIコンテンツを含むアプリケーションルートオブジェクトです。
Windows Presentation Foundation（WPF）アプリケーションでは、シェルはWindowオブジェクトです。

シェルは、アプリケーションのレイアウト構造を提供するマスターページの役割を果たします。
シェルには、モジュールが表示されるビューを指定できる1つ以上の名前付き領域が含まれています。
また、背景、メインメニュー、ツールバーなど、特定のトップレベルのUI要素を定義することもできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/5aca0d17-242f-2d87-61a5-792eadbde8bb.png)

```
The shell defines the overall appearance of the application.
It might define styles and borders that are present and visible in the shell layout itself, and it might also define styles, templates, and themes that will be applied to the views that are plugged into the shell.

Typically, the shell is a part of the WPF application project.
The assembly that contains the shell might or might not reference the assemblies that contain the views to be loaded in the shell's regions.
```
シェルは、アプリケーションの全体的な外観を定義します。
シェルレイアウト自体に存在し、表示されるスタイルと境界線を定義し、シェルにプラグインされているビューに適用されるスタイル、テンプレート、テーマを定義することもできます。

通常、シェルはWPFアプリケーションプロジェクトの一部です。
シェルを含むアセンブリは、シェルの領域にロードされるビューを含むアセンブリを参照する場合としない場合があります。

###Views
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/24562c30-0602-06a2-6317-ae053942c3b3.png)

```
Views are the main unit of UI construction within a composite application.
You can define a view as a user control, page, data template, or custom control.
A view encapsulates a portion of your UI that you would like to keep as decoupled as possible from other parts of the application.
You can choose what goes in a view based on encapsulation or a piece of functionality, or you can choose to define something as a view because you will have multiple instances of that view in your application.

Because of the content model of WPF, there is nothing specific to the Prism Library required to define a view.
The easiest way to define a view is to define a user control.
To add a view to the UI, you simply need a way to construct it and add it to a container.
WPF provides mechanisms to do this. The Prism Library adds the ability to define a region into which a view can be dynamically added at run time.
```
ビューは、複合アプリケーション内のUI構築の主要な単位です。
ビューは、ユーザーコントロール、ページ、データテンプレート、またはカスタムコントロールとして定義できます。
ビューは、アプリケーションの他の部分から可能な限り分離したままにしたいUIの一部をカプセル化します。
カプセル化または機能の一部に基づいてビューの内容を選択するか、アプリケーションにそのビューの複数のインスタンスがあるため、ビューとして何かを定義することを選択できます。

WPFのコンテンツモデルのため、ビューの定義に必要なプリズムライブラリに固有のものはありません。
ビューを定義する最も簡単な方法は、ユーザーコントロールを定義することです。
ビューをUIに追加するには、ビューを作成してコンテナに追加する方法が必要です。
WPFはこれを行うためのメカニズムを提供します。 Prism Libraryは、実行時にビューを動的に追加できる領域を定義する機能を追加します。

####Composite Views
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/89291373-56b5-2874-469d-48f122d60d40.png)

```
A view that supports specific functionality can become complicated.
In that case, you might want to divide the view into several child views and have the parent view handle constructing itself by using the child views as parts.
The application might do this statically at design time, or it might support having modules add child views through a contained region at run time.
When you have a view that is not fully defined in a single view class, you can refer to that as a composite view.
In many situations, a composite view is responsible for constructing the child views and for coordinating the interactions between them.
You can design child views that are more loosely coupled from their sibling views and their parent composite view by using the Prism Library commands and the event aggregator.
```
特定の機能をサポートするビューは複雑になる可能性があります。
その場合、ビューをいくつかの子ビューに分割し、子ビューをパーツとして使用して親ビューハンドル自体を構築することができます。
アプリケーションはこれを設計時に静的に実行するか、実行時に含まれる領域を介してモジュールに子ビューを追加させることをサポートする場合があります。
単一のビュークラスで完全に定義されていないビューがある場合、そのビューを複合ビューとして参照できます。
多くの状況で、複合ビューは子ビューの作成と子ビュー間の相互作用の調整を担当します。
Prism Libraryコマンドとイベントアグリゲーターを使用して、兄弟ビューとその親複合ビューからより疎結合な子ビューを設計できます。

###Regions
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/21afd8d3-7291-fe94-ed56-71eec29bc4bb.png)

```
Regions are enabled in the Prism Library through a region manager, regions, and region adapters.
```
Prism Libraryでは、リージョンマネージャー、リージョン、リージョンアダプターを介してリージョンが有効になります。

####Region Manager
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/b56bbdc6-b205-10dd-0e45-112606a40752.png)

```
The RegionManager class is responsible for creating and maintaining a collection of regions for the host controls. 
The RegionManager uses a control-specific adapter that associates a new region with the host control.
The following illustration shows the relationship between the region, control, and adapter set up by the RegionManager.
```
RegionManagerクラスは、ホストコントロールの領域のコレクションの作成と維持を担当します。
RegionManagerは、新しい領域をホストコントロールに関連付けるコントロール固有のアダプターを使用します。
次の図は、RegionManagerによって設定された領域、コントロール、およびアダプター間の関係を示しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/a064873c-4eb1-fcb8-4ccf-d0af34100c3e.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/e524bc73-456f-96bd-304e-f5058d4f9b75.png)

```
The RegionManager can create regions in code or in XAML.
The RegionManager.RegionName attached property is used to create a region in XAML by applying the attached property to the host control.

Applications can contain one or more instances of a RegionManager.
You can specify the RegionManager instance into which you want to register the region.
This is useful if you want to move the control around in the visual tree and do not want the region to be cleared when the attached property value is removed.

The RegionManager provides a RegionContext attached property that permits its regions to share data.
```
RegionManagerは、コードまたはXAMLで領域を作成できます。
RegionManager.RegionName添付プロパティを使用して、添付プロパティをホストコントロールに適用することにより、XAMLで領域を作成します。

アプリケーションには、RegionManagerの1つ以上のインスタンスを含めることができます。
リージョンを登録するRegionManagerインスタンスを指定できます。
これは、ビジュアルツリー内でコントロールを移動する必要があり、添付されたプロパティ値が削除されたときに領域がクリアされないようにする場合に役立ちます。

RegionManagerは、リージョンがデータを共有できるようにするRegionContext添付プロパティを提供します。

####Region Implementation
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/ac0424b3-136c-1f2a-7f15-d937206f3927.png)

```
A region is a class that implements the IRegion interface.
The term region represents a container that can hold dynamic data that is presented in a UI.
A region allows the Prism Library to place dynamic content contained in modules in predefined placeholders in a UI container.

Regions can hold any type of UI content.
A module can contain UI content presented as a user control, a data type that is associated with a data template, a custom control, or any combination of these.
This lets you define the appearance for the UI areas and then have modules place content in these predetermined areas.
```
リージョンは、IRegionインターフェースを実装するクラスです。
領域という用語は、UIに表示される動的データを保持できるコンテナーを表します。
リージョンにより、Prism Libraryはモジュールに含まれる動的コンテンツをUIコンテナー内の事前定義されたプレースホルダーに配置できます。

リージョンは、あらゆるタイプのUIコンテンツを保持できます。
モジュールには、ユーザーコントロール、データテンプレートに関連付けられているデータ型、カスタムコントロール、またはこれらの任意の組み合わせとして表示されるUIコンテンツを含めることができます。
これにより、UI領域の外観を定義し、モジュールにこれらの事前定義された領域にコンテンツを配置させることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/4d3b354e-77a6-ba65-433d-2bfbd039d4eb.png)

```
A region can contain zero or more items.
Depending on the type of host control the region is managing, one or more of the items could be visible.
For example, a ContentControl can display only a single object.
However, the region in which it is located can contain many items, and an ItemsControl can display multiple items.
This allows each item in the region to be visible in the UI.

In the following illustration, the sample app shell contains four regions: MainRegion, MainToolbarRegion, ResearchRegion, and ActionRegion.
These regions are populated by the various modules in the application—the content can be changed at any time.
```
リージョンには、0個以上のアイテムを含めることができます。
リージョンが管理しているホストコントロールのタイプに応じて、1つ以上のアイテムが表示される場合があります。
たとえば、ContentControlは1つのオブジェクトのみを表示できます。
ただし、それが配置されている領域には多くのアイテムを含めることができ、ItemsControlは複数のアイテムを表示できます。
これにより、領域内の各アイテムをUIに表示できます。

次の図では、サンプルアプリシェルにMainRegion、MainToolbarRegion、ResearchRegion、ActionRegionの4つのリージョンが含まれています。
これらの領域には、アプリケーションのさまざまなモジュールが入力されます。コンテンツはいつでも変更できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/049c5c8b-ae53-d60a-66b7-405bea2874a6.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/b6fddce7-c629-b831-2fbd-0a7636bba82b.png)

```
Module User Control to Region Mapping
To demonstrate how modules and content are associated with regions, see the following illustration.
It shows the association of WatchModule and the NewsModule with the corresponding regions in the shell.

The MainRegion contains the WatchListView user control, which is contained in the WatchModule.
The ResearchRegion also contains the ArticleView user control, which is contained in the NewsModule.
```
#####モジュールユーザーコントロールから領域へのマッピング
モジュールとコンテンツがどのようにリージョンに関連付けられているかを示すには、次の図を参照してください。
これは、WatchModuleおよびNewsModuleと、シェル内の対応する領域との関連付けを示しています。

MainRegionには、WatchModuleに含まれているWatchListViewユーザーコントロールが含まれています。
ResearchRegionには、NewsModuleに含まれているArticleViewユーザーコントロールも含まれています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/98182d36-5978-9bbf-5b7b-956e9a1bc194.png)

```
In applications created with the Prism Library, mappings like this will be a part of the design process because designers and developers use them to determine what content is proposed to be in a specific region.
This allows designers to determine the overall space needed and any additional items that must be added to ensure that the content will be viewable in the allowable space.
```
Prism Libraryで作成されたアプリケーションでは、このようなマッピングは設計プロセスの一部になります。デザイナーと開発者がそれらを使用して、特定の領域にあると提案されているコンテンツを決定するためです。
これにより、デザイナーは必要な全体的なスペースと、コンテンツが許容されるスペースで確実に表示されるようにするために追加する必要がある追加のアイテムを決定できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/fa888360-4284-09aa-b397-b7ab5a4c4951.png)

####Default Region Functionality
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/338e909a-e5fc-0ede-077c-2c76408d2eca.png)

```
While you do not need to fully understand region implementations to use them, it might be useful to understand how controls and regions are associated and the default region functionality:
for example, how a region locates and instantiates views, how views can be notified when they are the active view, or how view lifetime can be tied to activation.

The following sections describe the region adapter and region behaviors.
```
それらを使用するために領域の実装を完全に理解する必要はありませんが、コントロールと領域がどのように関連付けられているか、およびデフォルトの領域の機能を理解しておくと役立つ場合があります。
たとえば、リージョンがビューを見つけてインスタンス化する方法、ビューがアクティブビューになったときにビューに通知する方法、ビューの有効期間をアクティブ化に関連付ける方法などです。

次のセクションでは、リージョンアダプターとリージョンの動作について説明します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/79fdd2c6-6da6-8ad3-1283-765c4103029a.png)

```
Region Adapter
To expose a UI control as a region, it must have a region adapter.
Region adapters are responsible for creating a region and associating it with the control.
This allows you to use the IRegion interface to manage the UI control contents in a consistent way.
Each region adapter adapts a specific type of UI control. The Prism Library provides the following three region adapters:

・ContentControlRegionAdapter. 
This adapter adapts controls of type System.Windows.Controls.ContentControl and derived classes.
・SelectorRegionAdapter.
This adapter adapts controls derived from the class System.Windows.Controls.Primitives.Selector, such as the System.Windows.Controls.TabControl control.
・ItemsControlRegionAdapter.
This adapter adapts controls of type System.Windows.Controls.ItemsControl and derived classes.
```
#####Region Adapter
UIコントロールを領域として公開するには、領域アダプタが必要です。
リージョンアダプタは、リージョンを作成し、それをコントロールに関連付けます。
これにより、IRegionインターフェイスを使用して、UIコントロールのコンテンツを一貫した方法で管理できます。
各リージョンアダプターは、特定のタイプのUIコントロールを適合させます。 Prism Libraryは、次の3つのリージョンアダプターを提供します。

・ContentControlRegionAdapter。
このアダプターは、System.Windows.Controls.ContentControlタイプのコントロールと派生クラスを適合させます。
・SelectorRegionAdapter。
このアダプターは、System.Windows.Controls.TabControlコントロールなど、System.Windows.Controls.Primitives.Selectorクラスから派生したコントロールを適合させます。
・ItemsControlRegionAdapter。
このアダプターは、System.Windows.Controls.ItemsControlタイプのコントロールと派生クラスを適合させます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/02e1a3b5-7618-1223-5068-c3856ae1ac89.png)

```
Region Behaviors
The Prism Library introduces the concept of region behaviors.
These are pluggable components that give a region most of its functionality.
Region behaviors were introduced to support view discovery and region context (described later in this topic).
Additionally, behaviors provide an effective way to extend a region's implementation.
```

#####Region Behaviors
Prism Libraryは、リージョンの動作の概念を導入しています。
これらは、リージョンのほとんどの機能を提供するプラグイン可能なコンポーネントです。
領域の動作は、ビューの検出と領域のコンテキストをサポートするために導入されました（このトピックで後ほど説明します）。
さらに、動作は、リージョンの実装を拡張する効果的な方法を提供します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/6b8ed346-9bac-ff74-ea19-9921d119b018.png)

```
A region behavior is a class that is attached to a region to give the region additional functionality.
This behavior is attached to the region and remains active for the lifetime of the region.
For example, when an AutoPopulateRegionBehavior is attached to a region, it automatically instantiates and adds any ViewTypes that are registered against regions with that name.
For the lifetime of the region, it keeps monitoring the RegionViewRegistry for new registrations.
It is easy to add custom region behaviors or replace existing behaviors, either on a system-wide or a per-region basis.

The next sections describe the default behaviors that are automatically added to all regions.
One behavior, the SelectorItemsSourceSyncBehavior, is only attached to controls that derive from the Selector.
```
リージョンの動作は、リージョンに追加機能を提供するためにリージョンにアタッチされるクラスです。
この動作はリージョンに関連付けられ、リージョンの存続期間中アクティブのままです。
たとえば、AutoPopulateRegionBehaviorがリージョンにアタッチされると、その名前のリージョンに対して登録されているすべてのViewTypeが自動的にインスタンス化されて追加されます。
リージョンの存続期間中、RegionViewRegistryを監視して新しい登録を探します。
システム全体またはリージョンごとに、カスタムリージョンの動作を追加したり、既存の動作を置き換えたりするのは簡単です。

次のセクションでは、すべてのリージョンに自動的に追加されるデフォルトの動作について説明します。
1つの動作であるSelectorItemsSourceSyncBehaviorは、セレクターから派生したコントロールにのみアタッチされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/c80f6a63-01f8-9ab7-edfb-a9ac53890d0c.png)

```
Registration Behavior
The RegionManagerRegistrationBehavior is responsible for making sure that the region is registered to the correct RegionManager.
When a view or control is added to the visual tree as a child of another control or region, any region defined in the control should be registered in the RegionManager of the parent control.
When the child control is removed, the registered region is unregistered.
```
#####Registration Behavior
RegionManagerRegistrationBehaviorは、リージョンが正しいRegionManagerに登録されていることを確認する責任があります。
ビューまたはコントロールが別のコントロールまたは領域の子としてビジュアルツリーに追加された場合、コントロールで定義された領域は、親コントロールのRegionManagerに登録する必要があります。
子コントロールが削除されると、登録された領域は登録解除されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/f07db3b2-c37f-baa4-e055-f4712ba42729.png)

```
Auto-Population Behavior
There are two classes responsible for implementing view discovery.
One of them is the AutoPopulateRegionBehavior.
When it is attached to a region, it retrieves all view types that are registered under the name of the region.
It then creates instances of those views and adds them to the region.
After the region is created, the AutoPopulateRegionBehavior monitors the RegionViewRegistry for any newly registered view types for that region name.

If you want to have more control over the view discovery process, consider creating your own implementation of the IRegionViewRegistry and the AutoPopulateRegionBehavior.
```
#####Auto-Population Behavior
ビュー検出の実装を担当する2つのクラスがあります。
それらの1つはAutoPopulateRegionBehaviorです。
リージョンにアタッチされている場合、リージョンの名前で登録されているすべてのビュータイプを取得します。
次に、それらのビューのインスタンスを作成し、それらをリージョンに追加します。
リージョンが作成された後、AutoPopulateRegionBehaviorはRegionViewRegistryを監視して、そのリージョン名に新しく登録されたビュータイプを探します。

ビュー検出プロセスをさらに制御したい場合は、IRegionViewRegistryとAutoPopulateRegionBehaviorの独自の実装を作成することを検討してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/3ddeb363-e70c-7149-7271-53d72be77cb1.png)

```
Region Context Behaviors
The region context functionality is contained within two behaviors: the SyncRegionContextWithHostBehavior and the BindRegionContextToDependencyObjectBehavior.
These behaviors are responsible for monitoring changes to the context that were made on the region, and then synchronizing the context with a context dependency property attached to the view.
```
#####Region Context Behaviors
リージョンコンテキスト機能は、SyncRegionContextWithHostBehaviorとBindRegionContextToDependencyObjectBehaviorの2つの動作に含まれています。
これらの動作は、リージョンで行われたコンテキストへの変更を監視し、コンテキストをビューに関連付けられているコンテキスト依存関係プロパティと同期させる役割を果たします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/6d2c9f24-31ec-1d09-84ef-1985fbcf02fb.png)

```
Activation Behavior
The RegionActiveAwareBehavior is responsible for notifying a view if it is active or inactive.
The view must implement IActiveAware to receive these change notifications.
This active aware notification is one-directional (it travels from the behavior to the view).
The view cannot affect its active state by changing the active property on the IActiveAware interface.
```
#####Activation Behavior
RegionActiveAwareBehaviorは、ビューがアクティブか非アクティブかをビューに通知します。
これらの変更通知を受信するには、ビューにIActiveAwareを実装する必要があります。
このアクティブ対応の通知は一方向です（動作からビューに移動します）。
IActiveAwareインターフェイスのアクティブプロパティを変更しても、ビューはアクティブ状態に影響を与えません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/100fd2a5-0780-2322-5569-afbe98a4bba4.png)

```
Region Lifetime Behavior
The RegionMemberLifetimeBehavior is responsible for determining if an item should be removed from the region when it is deactivated.
The RegionMemberLifetimeBehavior monitors the region's ActiveViews collection to discover items that transition into a deactivated state.
The behavior checks the removed items for IRegionMemberLifetime or the RegionMemberLifetimeAttribute (in that order) to determine if it should be kept alive on removal.
```
#####Region Lifetime Behavior
RegionMemberLifetimeBehaviorは、非アクティブ化されたときにアイテムをリージョンから削除する必要があるかどうかを決定します。
RegionMemberLifetimeBehaviorは、領域のActiveViewsコレクションを監視して、非アクティブ状態に遷移するアイテムを検出します。
この動作は、IRegionMemberLifetimeまたはRegionMemberLifetimeAttributeの削除されたアイテムを（この順序で）チェックして、削除された後も維持するかどうかを決定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/bb2531fb-78ea-0e7a-76f9-302d9dace5d7.png)

```
If the item in the collection is a System.Windows.FrameworkElement, it will also check its DataContext for IRegionMemberLifetime or the RegionMemberLifetimeAttribute.

The region items are checked in the following order:

1. IRegionMemberLifetime.KeepAlive value
2. DataContext's IRegionMemberLifetime.KeepAlive value
3. RegionMemberLifetimeAttribute.KeepAlive value
4. DataContext's RegionMemberLifetimeAttribute.KeepAlive value
```
コレクション内の項目がSystem.Windows.FrameworkElementの場合、そのDataContextでIRegionMemberLifetimeまたはRegionMemberLifetimeAttributeを確認します。

リージョンアイテムは次の順序でチェックされます。

1. IRegionMemberLifetime.KeepAlive値
2. DataContextのIRegionMemberLifetime.KeepAlive値
3. RegionMemberLifetimeAttribute.KeepAlive値
4. DataContextのRegionMemberLifetimeAttribute.KeepAlive値

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/73801355-3279-3b22-e5cf-01513f4d9642.png)

```
Control-Specific Behaviors
The SelectorItemsSourceSyncBehavior is used only for controls that derive from Selector, such as a tab control in WPF.
It is responsible for synchronizing the views in the region with the items of the selector, and then synchronizing the active views in the region with the selected items of the selector.
```
#####Control-Specific Behaviors
SelectorItemsSourceSyncBehaviorは、WPFのタブコントロールなど、セレクターから派生するコントロールにのみ使用されます。
リージョン内のビューをセレクターのアイテムと同期し、リージョン内のアクティブなビューをセレクターの選択したアイテムと同期します。

###Extending the Region Implementation
リージョン実装の拡張
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/07ef10ad-5de0-4b6d-63b4-141c6bb5143b.png)

```
The Prism Library provides extension points that allow you to customize or extend the default behavior of the provided APIs.
For example, you can write your own region adapters, region behaviors, or change the way the Navigation API parses URIs.
```
Prism Libraryは、提供されたAPIのデフォルトの動作をカスタマイズまたは拡張できる拡張ポイントを提供します。
たとえば、独自のリージョンアダプターやリージョンの動作を記述したり、Navigation APIがURIを解析する方法を変更したりできます。

##View Composition
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/4f06365b-7b67-eade-ccfa-e2d4f00a18d1.png)

```
View composition is the constructing of a view. In composite applications, views from multiple modules have to be displayed at run time in specific locations within the application UI.
To achieve this, you need to define the locations where the views will appear and how the views will be created and displayed in those locations.

Views can be created and displayed in the locations either automatically through view discovery, or programmatically through view injection.
These two techniques determine how individual views are mapped to named locations within the application UI.
```
ビューの構成は、ビューの構築です。 複合アプリケーションでは、複数のモジュールのビューを、実行時にアプリケーションUI内の特定の場所に表示する必要があります。
これを実現するには、ビューが表示される場所と、それらの場所でビューが作成および表示される方法を定義する必要があります。

ビューは、ビューの検出を通じて自動的に、またはビューの挿入を通じてプログラムによって、ロケーションに作成および表示できます。
これら2つの手法は、個々のビューがアプリケーションUI内の名前付きの場所にどのようにマップされるかを決定します。

###View Discovery
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/5bb4249d-05a1-981b-f1c3-8c695fd139de.png)

```
In view discovery, you set up a relationship in the RegionViewRegistry between a region's name and the type of a view.
When a region is created, the region looks for all the ViewTypes associated with the region and automatically instantiates and loads the corresponding views.
Therefore, with view discovery, you do not have explicit control over when the views that correspond to a region are loaded and displayed.
```
ビューの検出では、RegionViewRegistryでリージョンの名前とビューのタイプとの関係を設定します。
リージョンが作成されると、リージョンはそのリージョンに関連付けられているすべてのViewTypeを探し、対応するビューを自動的にインスタンス化してロードします。
したがって、ビューの検出では、リージョンに対応するビューがいつ読み込まれて表示されるかを明示的に制御することはできません。

###View Injection
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/191ee84b-9ce3-05c2-ddf5-019b853e4441.png)

```
In view injection, your code obtains a reference to a region, and then programmatically adds a view into it.
Typically, this is done when a module initializes or as a result of a user action.
Your code will query a RegionManager for a specific region by name and then inject views into it.
With view injection, you have more control over when views are loaded and displayed.
You also have the ability to remove views from the region. However, with view injection, you cannot add a view to a region that has not yet been created.
```
ビューインジェクションでは、コードが領域への参照を取得し、プログラムによって領域にビューを追加します。
通常、これは、モジュールが初期化されるとき、またはユーザーアクションの結果として行われます。
コードは、RegionManagerに名前で特定の領域をクエリし、ビューをその領域に挿入します。
ビューインジェクションを使用すると、ビューをロードして表示するタイミングをより詳細に制御できます。
また、リージョンからビューを削除することもできます。 ただし、ビューの挿入では、まだ作成されていない領域にビューを追加することはできません。

###Navigation
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/70aedb9e-eff8-3cb0-213c-2355d6cbdc0a.png)

```
The Prism Library 7.1 contains Navigation APIs.
The Navigation APIs simplify the view injection process by allowing you to navigate a region to an URI.
The Navigation API instantiates the view, adds it to the region, and then activates it.
Additionally, the Navigation API allows navigating back to a previously created view contained in a region. For more information about the Navigation APIs, see Navigation.
```
Prism Library 7.1には、ナビゲーションAPIが含まれています。
Navigation APIは、URIにリージョンをナビゲートできるようにすることで、ビューインジェクションプロセスを簡素化します。
Navigation APIはビューをインスタンス化し、それを領域に追加してから、アクティブ化します。
さらに、Navigation APIを使用すると、領域に含まれている以前に作成したビューに戻ることができます。 ナビゲーションAPIの詳細については、ナビゲーションを参照してください。
###When to Use View Discovery vs. View Injection

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/d41766bc-5164-0477-a191-831aff18a6a7.png)

```
hoosing which view loading strategy to use for a region depends on the application requirements and the function of the region.

Use view discovery in the following situations:
・Automatic view loading is desired or required.
・Single instances of a view will be loaded into the region.

Use view injection in the following situations:
・Your application uses the Navigation APIs.
・You need explicit or programmatic control over when a view is created and displayed, or you need to remove a view from a region; for example, as a result of application logic or navigation.
・You need to display multiple instances of the same views in a region, where each view instance is bound to different data.
・You need to control which instance of a region a view is added to. For example, you want to add a customer detail view to a specific customer detail region. (This scenario requires implementing scoped regions as described later in this topic.)
```
リージョンに使用するビューのロード戦略の選択は、アプリケーションの要件とリージョンの機能によって異なります。

次の状況でView Discoveryを使用します。
・自動ビュー読み込みが望まれる、または必要とされる。
・ビューの単一インスタンスがリージョンにロードされます。

以下の状況でView Injectionを使用します。
・あなたのアプリケーションはナビゲーションAPIを使用しています。
・ビューを作成して表示するタイミングを明示的またはプログラム的に制御する必要がある、または領域からビューを削除する必要がある。 たとえば、アプリケーションロジックやナビゲーションの結果として。
・同じビューの複数のインスタンスをリージョンに表示する必要があります。各ビューインスタンスは異なるデータにバインドされています。
・ビューを追加するリージョンのインスタンスを制御する必要があります。 たとえば、特定の顧客詳細領域に顧客詳細ビューを追加するとします。 （このシナリオでは、このトピックの後半で説明するように、スコープ領域を実装する必要があります。）

##UI Layout Scenarios
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/db1f8a34-2ad0-dcac-7374-a339ad7e6d1d.png)

```
In composite applications, views from multiple modules are displayed at run time in specific locations within the application UI.
To achieve this, you need to define the locations where the views will appear and how the views will be created and displayed in those locations.

The decoupling of the view and the location in the UI in which it will be displayed allows the appearance and layout of the application to evolve independently of the views that appear within the region.

The next sections describe the core scenarios you will encounter when you develop a composite application.
```
複合アプリケーションでは、複数のモジュールのビューが、実行時にアプリケーションUI内の特定の場所に表示されます。
これを実現するには、ビューが表示される場所と、それらの場所でビューが作成および表示される方法を定義する必要があります。

ビューとそれが表示されるUI内の場所を分離することで、アプリケーションの外観とレイアウトを、領域内に表示されるビューとは無関係に展開できます。

次のセクションでは、複合アプリケーションを開発するときに発生する主要なシナリオについて説明します。

###Implementing the Shell
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/04849bdd-ba21-da35-4202-7f070f123c1e.png)

```
The shell is the application root object in which the primary UI content is contained.
In a WPF application, the shell is the Window object.

A shell can contain named regions where modules can specify the views that will appear.
It can also define certain top-level UI elements, such as the main menu and toolbar. The shell defines the overall structure and appearance for the application, and is similar to an ASP.NET master page control.
It could define styles and borders that are present and visible in the shell layout itself, and it could also define styles, templates, and themes that are applied to the views that are plugged into the shell.
```
シェルは、プライマリUIコンテンツが含まれるアプリケーションルートオブジェクトです。
WPFアプリケーションでは、シェルはWindowオブジェクトです。

シェルには、モジュールが表示されるビューを指定できる名前付き領域を含めることができます。
また、メインメニューやツールバーなど、特定のトップレベルのUI要素を定義することもできます。 シェルは、アプリケーションの全体的な構造と外観を定義し、ASP.NETマスターページコントロールに似ています。
シェルレイアウト自体に存在し、表示されるスタイルと境界線を定義できます。また、シェルに接続されているビューに適用されるスタイル、テンプレート、テーマを定義することもできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/c1a0f6c6-27c8-6ca0-a47a-2e762277aab4.png)

```
You do not need to have a distinct shell as part of your application architecture to use the Prism Library.
If you are building a completely new composite application, implementing a shell provides a well-defined root and initialization pattern for setting up the main UI of your application.
However, if you are adding Prism Library features to an existing application, you do not have to change the basic architecture of your application to add a shell.
Instead, you can alter your existing window definitions or controls to add regions that can pull in views as needed.

You can also have more than one shell in your application.
If your application is designed to open more than one top-level window for the user, each top-level window acts as shell for the content it contains.
```
Prism Libraryを使用するために、アプリケーションアーキテクチャの一部として別個のシェルを用意する必要はありません。
完全に新しい複合アプリケーションを構築している場合、シェルを実装すると、アプリケーションのメインUIをセットアップするための明確に定義されたルートと初期化パターンが提供されます。
ただし、Prism Library機能を既存のアプリケーションに追加する場合、アプリケーションの基本アーキテクチャを変更してシェルを追加する必要はありません。
代わりに、既存のウィンドウ定義またはコントロールを変更して、必要に応じてビューを取り込むことができる領域を追加できます。

アプリケーションに複数のシェルを含めることもできます。
アプリケーションがユーザーに対して複数のトップレベルウィンドウを開くように設計されている場合、各トップレベルウィンドウは、それが含むコンテンツのシェルとして機能します。

###Sample Shell
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/d7095082-8e37-969d-bc07-bb47851b9974.png)

```
This sample has a shell as its main window.
In the following illustration, the shell and views are highlighted.
The shell is the main window that appears when the app starts and which contains all the views.
It defines the regions into which modules add their views and a couple of top-level UI items, including the title and the Watch List tear-off banner.
```
このサンプルには、メインウィンドウとしてシェルがあります。
次の図では、シェルとビューが強調表示されています。
シェルは、アプリの起動時に表示されるメインウィンドウであり、すべてのビューが含まれています。
これは、モジュールがビューを追加する領域と、タイトルやウォッチリストのティアオフバナーなど、いくつかのトップレベルのUIアイテムを定義します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/294138f5-a6b5-d83b-a73b-c2a55762ffda.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/e3f74b57-4840-eb04-dd57-e37bc332bfa0.png)

```
The shell implementation in the app is provided by Shell.xaml, its code-behind file Shell.xaml.cs, and its view model ShellViewModel.cs.
Shell.xaml includes the layout and UI elements that are part of the shell, including definitions of regions to which modules add their views.

The following XAML shows the structure and main XAML elements that define the shell.
Notice that the RegionName attached property is used to define the four regions and that the window background image provides a background for the shell.
```
アプリのシェル実装は、Shell.xaml、その分離コードファイルShell.xaml.cs、およびビューモデルShellViewModel.csによって提供されます。
Shell.xamlには、モジュールがビューを追加する領域の定義など、シェルの一部であるレイアウトとUI要素が含まれています。

次のXAMLは、シェルを定義する構造と主要なXAML要素を示しています。
RegionName添付プロパティを使用して4つの領域を定義し、ウィンドウの背景画像がシェルの背景を提供していることに注意してください。

```
<!--Shell.xaml (WPF) -->
<Window x:Class="StockTraderRI.Shell">

    <!--shell background -->
    <Window.Background>
        <ImageBrush ImageSource="Resources/background.png" Stretch="UniformToFill"/>
    </Window.Background>

    <Grid>

        <!-- logo -->
        <Canvas x:Name="Logo" ...>
            <TextBlock Text="CFI" ... />
            <TextBlock Text="STOCKTRADER" .../>
        </Canvas>

        <!-- main bar -->
        <ItemsControl 
            x:Name="MainToolbar"
            prism:RegionManager.RegionName="{x:Static inf:RegionNames.MainToolBarRegion}"/>

        <!-- content -->
        <Grid>
            <Controls:AnimatedTabControl
                x:Name="PositionBuySellTab"
                prism:RegionManager.RegionName="{x:Static inf:RegionNames.MainRegion}"/>
        </Grid>

        <!-- details -->
        <Grid>
            <ContentControl
                x:Name="ActionContent"
                prism:RegionManager.RegionName="{x:Static inf:RegionNames.ActionRegion}"/>
        </Grid>

        <!-- sidebar -->
        <Grid x:Name="SideGrid">
            <Controls:ResearchControl
                prism:RegionManager.RegionName="{x:Static inf:RegionNames.ResearchRegion}" />
        </Grid>

    </Grid>
</Window>
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/52d03ee6-f1f0-e6ce-cde9-93620cc36518.png)

```
The implementation of the Shell code-behind file is very simple.
The Shell is exported so that when your App object creates it, its dependencies will be and added.
```
シェル分離コードファイルの実装は非常に簡単です。
シェルがエクスポートされるので、アプリオブジェクトがシェルを作成すると、その依存関係が追加されます。

```
// Shell.xaml.cs
[Export]
public partial class Shell : Window
{
    public Shell()
    {
        InitializeComponent();
    }
}
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/9ae5843a-37d1-4f07-f3aa-20f1492e1f36.png)

```
The minimal code in the code-behind file illustrates the power and simplicity of the composite application architecture and loose coupling between the shell and its constituent views.
```
分離コードファイル内の最小限のコードは、複合アプリケーションアーキテクチャの力と単純さ、およびシェルとその構成要素ビュー間の疎結合を示しています。

###Defining Regions
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/35b3913f-35b8-1361-2fe9-b5aee4fd99d2.png)

```
You define where views will appear by defining a layout with named locations, known as regions.
Regions act as placeholders for one or more views that will be displayed at run time.
Modules can locate and add content to regions in the layout without knowing how and where the region is displayed.
This allows the layout to change without affecting the modules that add the content to the layout.
```
リージョンと呼ばれる名前の付いた場所でレイアウトを定義することにより、ビューが表示される場所を定義します。
リージョンは、実行時に表示される1つ以上のビューのプレースホルダーとして機能します。
モジュールは、領域が表示される方法と場所を知らなくても、レイアウト内の領域を見つけて領域に追加できます。
これにより、レイアウトにコンテンツを追加するモジュールに影響を与えることなく、レイアウトを変更できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/58728967-9869-ad9e-fd46-43a25dc6d73b.png)

```
Regions are defined by assigning a region name to a WPF control, either in XAML as shown in the previous Shell.xaml file or in code.
Regions can be accessed by their region name. At run time, views are added to the named Region control, which then displays the view or views according to the layout strategy that the views implement.
For example, a tab control region will lay out its child views in a tabbed arrangement.
Regions support the addition or removal of views.
Views can be created and displayed in regions either programmatically or automatically.
In the Prism Library, the former is achieved through view injection and the latter through view discovery.
These two techniques determine how individual views are mapped to the named regions within the application UI.
```
領域は、前のShell.xamlファイルに示されているXAMLまたはコードで、WPFコントロールに領域名を割り当てることによって定義されます。
リージョンには、リージョン名でアクセスできます。 実行時に、ビューは名前付きリージョンコントロールに追加され、ビューが実装するレイアウト戦略に従って1つまたは複数のビューを表示します。
たとえば、タブコントロール領域は、その子ビューをタブ付きの配置でレイアウトします。
リージョンは、ビューの追加または削除をサポートします。
ビューは、プログラムでまたは自動的に、領域内で作成および表示できます。
Prism Libraryでは、前者はビューインジェクションを通じて、後者はビューディスカバリを通じて実現されます。
これらの2つの手法は、個々のビューがアプリケーションUI内の名前付き領域にどのようにマップされるかを決定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/62817951-730c-d16e-6c5e-621c82ec5fcf.png)

```
The shell of the application defines the application layout at the highest level;
for example, by specifying the locations for the main content and the navigation content, as shown in the following illustration.
Layout within these high-level views is similarly defined, allowing the overall UI to be recursively composed.
```
アプリケーションのシェルは、アプリケーションのレイアウトを最高レベルで定義します。
たとえば、次の図に示すように、メインコンテンツとナビゲーションコンテンツの場所を指定します。
これらの高レベルビュー内のレイアウトも同様に定義され、UI全体を再帰的に構成することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/d2816a87-0e92-d002-3832-695a86836673.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/2fc4a33d-4910-249c-05c6-0b978a837ce4.png)

```
Regions are sometimes used to define locations for multiple views that are logically related.
In this scenario, the region control is typically an ItemsControl-derived control that will display the views according to the layout strategy that it implements, such as in a stacked or tabbed layout arrangement.

Regions can also be used to define a location for a single view;
for example, by using a ContentControl. In this scenario, the region control displays only one view at a time, even if more than one view is mapped to that region location.
```
リージョンは、論理的に関連する複数のビューの場所を定義するために使用されることがあります。
このシナリオでは、領域コントロールは通常、ItemsControlから派生したコントロールであり、スタックまたはタブ付きのレイアウト配置など、実装するレイアウト戦略に従ってビューを表示します。

リージョンは、単一のビューの場所を定義するためにも使用できます。
たとえば、ContentControlを使用します。 このシナリオでは、リージョンの場所に複数のビューがマップされている場合でも、リージョンコントロールは一度に1つのビューのみを表示します。

###Sample App Shell Regions
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/cc8d252f-aeb9-9d53-eb05-29aced5940de.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/efcaa0a0-b575-d96c-df83-b7df9c4634be.png)

```
A multiple-view layout is also demonstrated in the example app ui when the application is buying or selling a stock.
The Buy/Sell area is a list-style region that shows multiple buy/sell views (OrderCompositeView) as part of its list, as shown in the following illustration.
```
マルチビューレイアウトは、アプリケーションが株を売買する場合のサンプルアプリuiにも示されています。
購入/販売エリアは、次の図に示すように、リストの一部として複数の購入/販売ビュー（OrderCompositeView）を表示するリストスタイルの領域です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/4117a5d6-f5b8-04d6-c178-40f814787efe.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/0af50e84-0098-cc48-4c11-4f9b5a9ab100.png)

```
The shell's ActionRegion contains the OrdersView.
The OrdersView contains the Submit All and Cancel All buttons as well as the OrdersRegion.
The OrdersRegion is attached to a ListBox control which displays multiple OrderCompositeViews.
```
シェルのActionRegionにはOrdersViewが含まれています。
OrdersViewには、Submit AllボタンとCancel Allボタン、およびOrdersRegionが含まれています。
OrdersRegionは、複数のOrderCompositeViewを表示するListBoxコントロールにアタッチされます。

####Adding a Region in XAML
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/b90381ff-9a7f-1293-341a-3d50e0df296c.png)

```
A region is a class that implements the IRegion interface.
The region is the container that holds content to be displayed by a control.

The RegionManager supplies an attached property that you can use for simple region creation in XAML.
To use the attached property, you must load the Prism Library namespace into the XAML and then use the RegionName attached property.
The following example shows how to use the attached property in a window with an AnimatedTabControl.

Notice the use of the x:Static markup extension to reference the MainRegion string constant.
This practice eliminates magic strings in the XAML.
```
リージョンは、IRegionインターフェースを実装するクラスです。
リージョンは、コントロールによって表示されるコンテンツを保持するコンテナです。

RegionManagerは、XAMLでの簡単な領域の作成に使用できる添付プロパティを提供します。
添付プロパティを使用するには、Prism LibraryネームスペースをXAMLにロードしてから、RegionName添付プロパティを使用する必要があります。
次の例は、AnimatedTabControlのあるウィンドウで添付プロパティを使用する方法を示しています。

MainRegion文字列定数を参照するためのx：Staticマークアップ拡張の使用に注意してください。
これにより、XAMLのマジックストリングが削除されます。

```
<!-- (WPF) -->
<Controls:AnimatedTabControl 
    x:Name="PositionBuySellTab"
    prism:RegionManager.RegionName="{x:Static inf:RegionNames.MainRegion}"/>
```
####Adding a Region by Using Code
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/3dc6dc1e-687d-30d8-2ae1-f15e9f843268.png)

```
The RegionManager can register regions directly without using XAML.
The following code example shows how to add a region to a control from the code-behind file.
First a reference to the region manager is obtained.
Then, using the RegionManager static methods SetRegionManager and SetRegionName, the region is attached to the UI's ActionContent control and then that region is named ActionRegion.
```
RegionManagerは、XAMLを使用せずに領域を直接登録できます。
次のコード例は、コードビハインドファイルからコントロールに領域を追加する方法を示しています。
まず、領域マネージャーへの参照が取得されます。
次に、RegionManager静的メソッドSetRegionManagerおよびSetRegionNameを使用して、領域をUIのActionContentコントロールにアタッチし、その領域にActionRegionという名前を付けます。

```
IRegionManager regionManager = ServiceLocator.Current.GetInstance<IRegionManager>();
RegionManager.SetRegionManager(this.ActionContent, regionManager);
RegionManager.SetRegionName(this.ActionContent, "ActionRegion");
```

###Displaying Views in a Region When the Region Loads
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/96fbbe3e-55e4-69cd-1b59-3fe7c7282ff2.png)

```
With the view discovery approach, modules can register views (view models or presentation models) for a specific named location.
When that location is displayed at run time, any views that have been registered for that location will be created and displayed within it automatically.

Modules register views with a registry.
The parent view queries this registry to discover the views that were registered for a named location.
After they are discovered, the parent view places those views on the screen by adding them to the placeholder control.

After the application is loaded, the composite view is notified to handle the placement of new views that have been added to the registry.

The following illustration shows the view discovery approach.
```
ビュー検出アプローチを使用すると、モジュールは特定の名前付き場所のビュー（ビューモデルまたはプレゼンテーションモデル）を登録できます。
実行時にその場所が表示されると、その場所に登録されているすべてのビューが自動的に作成され、その中に表示されます。

モジュールは、ビューをレジストリに登録します。
親ビューは、このレジストリにクエリを実行して、指定された場所に登録されたビューを検出します。
それらが検出された後、親ビューはそれらのビューをプレースホルダーコントロールに追加することによって画面に配置します。

アプリケーションが読み込まれた後、レジストリに追加された新しいビューの配置を処理するように複合ビューに通知されます。

次の図は、ビュー検出アプローチを示しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/c2e74ef9-c52f-d385-30d4-e794bf753e16.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/18827640-3fae-932a-012a-38bdf0d8e95d.png)

```
The Prism Library defines a standard registry, RegionViewRegistry, to register views for these named locations.

To show a view in a region, register the view with the region manager, as shown in the following code example.
You can directly register a view type with the region, in which case the view will be constructed by the dependency injection container and added to the region when the control hosting the region is loaded.
```
Prism Libraryは、これらの名前付きロケーションのビューを登録するために、RegionViewRegistryという標準レジストリを定義しています。

リージョン内のビューを表示するには、次のコード例に示すように、ビューをリージョンマネージャーに登録します。
ビュータイプを領域に直接登録できます。その場合、ビューは依存関係注入コンテナーによって構築され、領域をホストするコントロールが読み込まれるときに領域に追加されます。

```
// View discovery
this.regionManager.RegisterViewWithRegion("MainRegion", typeof(EmployeeView));
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/0a5bded5-4464-417c-18c4-ab92f9da16f1.png)

```
Optionally, you can provide a delegate that returns the view to be shown, as shown in the next example.
The region manager will display the view when the region is created.
```
オプションで、次の例に示すように、表示するビューを返すデリゲートを提供できます。
リージョンが作成されると、リージョンマネージャがビューを表示します。

```
// View discovery
this.regionManager.RegisterViewWithRegion("MainRegion", () => this.container.Resolve<EmployeeView>());
```
###Displaying Views in a Region Programmatically
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/552773e9-2920-d635-5c90-3305e693e113.png)

```
In the view injection approach, views are programmatically added or removed from a named location by the modules that manage them.
To enable this, the application contains a registry of named locations in the UI.
A module can use the registry to look up one of the locations and then programmatically inject views into it.
To make sure that locations in the registry can be accessed similarly, each of the named locations adheres to a common interface used to inject the view.
The following illustration shows the view injection approach.
```

538/5000
ビューインジェクションアプローチでは、ビューは、ビューを管理するモジュールによって、プログラムによって名前付きの場所に追加または削除されます。
これを可能にするために、アプリケーションにはUI内の名前付きの場所のレジストリが含まれています。
モジュールはレジストリを使用して場所の1つを検索し、プログラムでビューを挿入できます。
レジストリ内の場所に同様にアクセスできることを確認するために、名前付きの各場所は、ビューの挿入に使用される共通のインターフェイスに準拠しています。
次の図は、ビューインジェクションアプローチを示しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/7f2dfe5e-44c1-5091-9e35-98f55b186aa1.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/7e45da6e-8030-e882-8086-410049649187.png)

```
The Prism Library defines a standard registry, RegionManager, and a standard interface, IRegion, for access these locations.

To use view injection to add a view to a region, get the region from the region manager, and then call the Add method, as shown in the following code.
With view injection, the view is displayed only after the view is added to a region, which can happen when the module is loaded or when a user action completes a predefined action.
```
Prism Libraryは、これらの場所にアクセスするための標準レジストリ、RegionManager、および標準インターフェースIRegionを定義します。

ビューインジェクションを使用してビューをリージョンに追加するには、次のコードに示すように、リージョンマネージャーからリージョンを取得し、Addメソッドを呼び出します。
ビューの挿入では、ビューが領域に追加された後にのみビューが表示されます。これは、モジュールが読み込まれたとき、またはユーザーアクションが事前定義されたアクションを完了したときに発生する可能性があります。

```
// View injection
IRegion region = regionManager.Regions["MainRegion"];

var ordersView = container.Resolve<OrdersView>();
region.Add(ordersView, "OrdersView");
region.Activate(ordersView);
```

####Ordering Views in a Region
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/5c09e3f7-8d51-f0c4-73c8-55a90958e07e.png)

```
Whether it uses view discovery or view Injection, an application might need to order how views appear in a TabControl, ItemsControl, or any other control that displays multiple active views.
By default, views appear in the order that they were registered and added into the region.

When a composite application is built, views are often registered from different modules.
Declaring dependencies between modules can help alleviate the problem, but when modules and views do not have any real interdependencies, declaring an artificial dependency couples modules unnecessarily.

To allow views to participate in ordering themselves, the Prism Library provides the ViewSortHint attribute.
This attribute contains a string Hint property that allows a view to declare a hint of how it should be ordered in the region.
```
ビュー検出またはビューインジェクションのどちらを使用する場合でも、アプリケーションは、TabControl、ItemsControl、または複数のアクティブビューを表示するその他のコントロールでのビューの表示方法を順序付けする必要がある場合があります。
デフォルトでは、ビューは登録されてリージョンに追加された順序で表示されます。

複合アプリケーションが構築されると、多くの場合、ビューは異なるモジュールから登録されます。
モジュール間の依存関係を宣言すると問題を軽減できますが、モジュールとビューに実際の相互依存関係がない場合、人工的な依存関係を宣言すると、モジュールが不必要に結合されます。

ビューがそれ自体の順序に参加できるようにするために、Prism LibraryにはViewSortHint属性が用意されています。
この属性には、ビューが領域内での順序付けのヒントを宣言できるようにする文字列Hintプロパティが含まれています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/361176b7-a353-c5c8-2f97-0a5f764b48e2.png)

```
When displaying views, the Region class uses a default view sorting routine that uses the hint to order the views.
This is a simple case-sensitive ordinal sort.
Views that have the sort hint attribute are ordered ahead of those without.
Also, those without the attribute appear in the order they were added to the region.

If you want to change how views are ordered, the Region class provides a SortComparison property that you can set with your own Comparison<_object_> delegate method.
It is important to note that the ordering of the region's Views and ActiveViews properties are reflected in the UI because adapters such as the ItemsControlRegionAdapter bind directly to these properties.
A custom region adapter could implement its own sorting and filter that will override how the region orders views.
```
ビューを表示するとき、Regionクラスは、ヒントを使用してビューを並べ替えるデフォルトのビューソートルーチンを使用します。
これは、大文字と小文字を区別する単純な序数ソートです。
ソートヒント属性のあるビューは、ビューのないビューよりも優先されます。
また、属性のないものは、リージョンに追加された順に表示されます。

ビューの順序付け方法を変更する場合、RegionクラスにはSortComparisonプロパティがあり、独自のComparison <_object_>デリゲートメソッドで設定できます。
ItemsControlRegionAdapterなどのアダプターはこれらのプロパティに直接バインドするため、領域のViewsプロパティとActiveViewsプロパティの順序がUIに反映されることに注意することが重要です。
カスタム領域アダプターは、領域がビューを順序付ける方法をオーバーライドする独自の並べ替えとフィルターを実装できます。

###Sharing Data Between Multiple Regions
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/6a5bcff7-ae83-09b6-1f67-aae54baba732.png)

```
The Prism Library provides multiple approaches to communicating between views, depending on your scenario.
The region manager provides the RegionContext property as one of these approaches.

RegionContext is useful when you want to share context between a parent view and child views that are hosted in a region.
RegionContext is an attached property.
You set the value of the context on the region control so that it can be made available to all child views that are displayed in that region control.
The region context can be any simple or complex object and can be a data-bound value.
The RegionContext can be used with either view discovery or view injection.
```
Prism Libraryは、シナリオに応じて、ビュー間の通信に複数のアプローチを提供します。
領域マネージャーは、これらのアプローチの1つとしてRegionContextプロパティを提供します。

RegionContextは、リージョンでホストされている親ビューと子ビューの間でコンテキストを共有する場合に便利です。
RegionContextは添付プロパティです。
領域コントロールにコンテキストの値を設定して、その領域コントロールに表示されるすべての子ビューで使用できるようにします。
リージョンコンテキストは、任意の単純または複雑なオブジェクトにすることができ、データバインド値にすることができます。
RegionContextは、ビューディスカバリーまたはビューインジェクションで使用できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/4472fa8f-86f7-a5b9-ca4a-0d5193d2b8fd.png)

```
Note: The DataContext property in WPF is used to set the local data context for the view. It allows the view to use data binding to communicate with a view model, local presenter, or model. RegionContext is used to share context between multiple views and is not local to a single view. It provides a simple mechanism for sharing context between multiple views.

The following code shows how the RegionContext attached property is used in XAML.
```
注：WPFのDataContextプロパティは、ビューのローカルデータコンテキストを設定するために使用されます。 これにより、ビューはデータバインディングを使用して、ビューモデル、ローカルプレゼンター、またはモデルと通信できます。 RegionContextは、複数のビュー間でコンテキストを共有するために使用され、単一のビューにローカルではありません。 複数のビュー間でコンテキストを共有するためのシンプルなメカニズムを提供します。

次のコードは、RegionContext添付プロパティがXAMLでどのように使用されるかを示しています。

```
<TabControl AutomationProperties.AutomationId="DetailsTabControl" 
    prism:RegionManager.RegionName="{x:Static local:RegionNames.TabRegion}"
    prism:RegionManager.RegionContext="{Binding Path=SelectedEmployee.EmployeeId}"
...>
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/5cc4e10e-f499-7e5e-d0d1-04f574570eba.png)

```
You can also set the RegionContext in code, as shown in the following example.
```
次の例に示すように、RegionContextをコードで設定することもできます。

```
RegionManager.Regions["Region1"].Context = employeeId;
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/1b723096-a158-1edf-c6bd-37935a7218d6.png)

```
To retrieve the RegionContext in a view, the GetObservableContext static method of the RegionContext class is used.
It passes the view as a parameter and then accesses its Value property, as shown in the following code example.
```
ビューでRegionContextを取得するには、RegionContextクラスのGetObservableContext静的メソッドを使用します。
次のコード例に示すように、ビューをパラメーターとして渡し、そのValueプロパティにアクセスします。

```
private void GetRegionContext()
{
    this.Model.EmployeeId = (int)RegionContext.GetObservableContext(this).Value;
}
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/1c9d00a7-4bee-02af-5440-104f62110b70.png)

```
The value of the RegionContext can be changed from within a view by simply assigning a new value to its Value property.
Views can opt to be notified of changes to the RegionContext by subscribing to the PropertyChanged event on the ObservableObject that is returned by the GetObservableContext method.
This allows multiple views to be kept in synchronization when their RegionContext is changed.
The following code example demonstrates subscribing to the PropertyChanged event.
```
RegionContextの値は、Valueプロパティに新しい値を割り当てるだけで、ビュー内から変更できます。
ビューは、GetObservableContextメソッドによって返されるObservableObjectのPropertyChangedイベントをサブスクライブすることにより、RegionContextへの変更の通知を受け取ることを選択できます。
これにより、RegionContextが変更されたときに複数のビューの同期を維持できます。
次のコード例は、PropertyChangedイベントのサブスクライブを示しています。

```
ObservableObject<object> viewRegionContext = 
                RegionContext.GetObservableContext(this);
viewRegionContext.PropertyChanged += this.ViewRegionContext_OnPropertyChangedEvent;

private void ViewRegionContext_OnPropertyChangedEvent(object sender, 
                    PropertyChangedEventArgs args)

{
    if (args.PropertyName == "Value")
    {
        var context = (ObservableObject<object>) sender;
        int newValue = (int)context.Value;
    }
}
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/2de59266-f86a-86e0-93a5-f065f45e0589.png)

```
Note: The RegionContext is set as an attached property on the content object hosted in the region. This means that the content object has to derive from DependencyObject. In the preceding example, the view is a visual control, which ultimately derives from DependencyObject.

If you choose to use WPF data templates to define your view, the content object will represent the ViewModel or PresentationModel. If your view model or presentation model needs to retrieve the RegionContext, it will need to derive from the DependencyObject base class.
```
注：RegionContextは、リージョンでホストされているコンテンツオブジェクトの添付プロパティとして設定されます。 つまり、コンテンツオブジェクトはDependencyObjectから派生する必要があります。 上記の例では、ビューは視覚的なコントロールであり、最終的にDependencyObjectから派生しています。

WPFデータテンプレートを使用してビューを定義することを選択した場合、コンテンツオブジェクトはViewModelまたはPresentationModelを表します。 ビューモデルまたはプレゼンテーションモデルがRegionContextを取得する必要がある場合は、DependencyObject基本クラスから派生する必要があります。

###Creating Multiple Instances of a Region
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/f9cb9939-8dbb-f34d-d212-537ab030112a.png)

```
Scoped regions are available only with view injection. You should use them if you need a view to have its own instance of a region. Views that define regions with attached properties automatically inherit their parent's RegionManager. Usually, this is the global RegionManager that is registered in the shell window. If the application creates more than one instance of that view, each instance would attempt to register its region with the parent RegionManager. RegionManager allows only uniquely named regions; therefore, the second registration would produce an error.

Instead, use scoped regions so that each view will have its own RegionManager and its regions will be registered with that RegionManager rather than the parent RegionManager, as shown in the following illustration.
```
スコープリージョンは、ビューインジェクションでのみ使用できます。 ビューにリージョンの独自のインスタンスが必要な場合は、これらを使用する必要があります。 プロパティがアタッチされた領域を定義するビューは、親のRegionManagerを自動的に継承します。 通常、これはシェルウィンドウに登録されているグローバルなRegionManagerです。 アプリケーションがそのビューの複数のインスタンスを作成する場合、各インスタンスはその領域を親RegionManagerに登録しようとします。 RegionManagerは一意に名前が付けられた領域のみを許可します。 したがって、2回目の登録ではエラーが発生します。

代わりに、次の図に示すように、スコープ付き領域を使用して、各ビューに独自のRegionManagerがあり、その領域が親RegionManagerではなくそのRegionManagerに登録されるようにします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/6d0b2c7d-2190-6756-cf02-390f1bcda2c2.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/c3ee88e0-83ea-a0a9-9b4a-917b6c1c10e4.png)

```
To create a local RegionManager for a view, specify that a new RegionManager should be created when you add your view to a region, as illustrated in the following code example.
```
ビューのローカルRegionManagerを作成するには、次のコード例に示すように、ビューをリージョンに追加するときに新しいRegionManagerを作成するように指定します。

```
IRegion detailsRegion = this.regionManager.Regions["DetailsRegion"];
View view = new View();
bool createRegionManagerScope = true;
IRegionManager detailsRegionManager = detailsRegion.Add(view, null, createRegionManagerScope);
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225878/4addee81-9074-0935-cc47-fa37dc3473a3.png)

```
The Add method will return the new RegionManager that the view can retain for further access to the local scope.
```
Addメソッドは、ローカルスコープにさらにアクセスするためにビューが保持できる新しいRegionManagerを返します。