Prism開発者ガイド-パート3、コンポーネント間の依存関係の管理

目次

1. はじめに
2. Prismアプリケーションの初期化
3. コンポーネント間の依存関係の管理
4. モジュラーアプリケーション開発
5. MVVMパターンの実装
6. 高度なMVVMシナリオ
7. ユーザーインターフェイスの作成
   
   1. ユーザーインターフェイスのガイドライン
8. ナビゲーション
   1. ビューベースのナビゲーション
9. 疎結合コンポーネント間の相互作用

Prismライブラリを使用して作成されるアプリケーションは、通常、疎結合のサービスとコンポーネントで構成される可能性のある複合アプリケーションです。 ユーザーインターフェイスにコンテンツを提供し、ユーザーアクションの通知を受信できるように、相互に対話する必要があります。 それらは疎結合であるため、相互作用の方法が必要であり、それなしでは必要な機能を取得できません。

すべての部品をリンクするために、PrismアプリケーションはDIコンテナーに依存しています。 DIコンテナーは、コンテナーの構成に応じてクラスをインスタンス化し、存続期間を管理する方法を提供することにより、オブジェクト間の依存関係を減らします。 コンテナを使用してオブジェクトを作成する場合、必要な依存関係をそれらに注入します。 依存関係がまだ作成されていない場合、最初にコンテナがそれらを作成し、独自の依存関係を解決します。 場合によっては、コンテナ自体が依存関係として挿入されます。 たとえば、Unityを使用する場合、モジュールにビューとサービスを登録できるように、コンテナーがモジュールに埋め込まれます。

コンテナを使用することにはいくつかの利点があります。

• コンテナにより、コンポーネントがその依存関係を特定したり、ライフタイムを制御したりする必要がなくなります。
• コンテナを使用すると、コンポーネントに影響を与えることなく実装を置き換えることができます。
• コンテナはテスト容易性を促進し、オブジェクトに偽の依存関係を埋め込むことができます。
• コンテナは、システムに新しいコンポーネントを簡単に追加できるようにすることで、メンテナンスを簡素化します。

Prismライブラリに基づくアプリケーションのコンテキストでは、コンテナを使用することには特定の利点があります。

• コンテナは、ロード時にモジュールの依存関係を解決します。
• コンテナは、プレゼンテーションモデルとビューの登録と作成に使用されます。
• コンテナは、ビューモデルを作成し、ビューを埋め込むことができます。
• コンテナーは、リージョンマネージャーやイベントアグリゲーターなどの複合アプリケーションサービスを実装します。
• コンテナは、モジュール固有のサービスをモジュール固有の機能に登録するために使用されます。

ご注意
Prismマニュアルの一部の例では、Unity Application Block（Unity）コンテナーを使用しています。 Modularity QuickStartsなどのその他のものは、Managed Extensibility Framework（MEF）を使用します。 Prismのライブラリ自体は使用されるコンテナに依存せず、CastleWindsor、Autofac、Structuremap、Spring.NETなどのその他のコンテナでそのサービスとパターンを使用できます。

重要な決定：依存性注入コンテナーの選択

Prismライブラリは、UnityとMEFの2つのデフォルトDIコンテナを提供します。 Prismは拡張可能であるため、少量のコードを記述してそれらを適合させることにより、他のコンテナを使用できます。 UnityとMEFは、非常に異なる動作をしますが、依存関係の実装に必要な同じ基本機能を提供します。 両方のコンテナが提供する機能の一部：

• どちらも、コンテナにタイプを登録できます。
• どちらも、コンテナにインスタンスを登録できます。
• どちらも、登録済みタイプのインスタンスを強制することができます。
• どちらも、登録済みタイプのインスタンスをコンストラクターに注入します。
• どちらも、プロパティに登録済みタイプのインスタンスを埋め込みます。
• どちらにも、タイプと依存関係を管理するための宣言属性があります。
• どちらもオブジェクトのグラフの依存関係を解決します。

Unityは、MEFにはないいくつかの機能を提供します。

• 登録せずに特定のタイプを許可します。
• オープン汎化（ Generics ）を許可します。
• メソッド呼び出しのインターセプトを使用して、ターゲットに追加機能を追加できます（ Interception ）。

MEFは、Unityでは利用できないいくつかの機能を提供します。

• ファイルシステムディレクトリ内のアセンブリを個別に検出します。
• XAPファイルをロードし、その中のアセンブリを探します。
• 新しいタイプが検出されたときに、プロパティとコレクションの再構成を実行します。
• 派生型を自動的にエクスポートします。
• 4番目のバージョンから始まる.NET Frameworkが付属しています。

コンテナは機能が異なり、動作も異なりますが、Prismライブラリはどのコンテナでも動作でき、同じ機能を提供します。 どのコンテナを使用するかを検討するときは、以前の経験を念頭に置き、どのコンテナがアプリケーションスクリプトに最適かを判断してください。

コンテナの考慮事項

コンテナを使用する前に考慮すべきこと：

• コンテナを使用してコンポーネントを登録および解決することが適切かどうかを検討してください。
  
  • コンテナに登録してインスタンスを解決する際のパフォーマンスへの影響があなたのケースで許容できるかどうかを検討してください。 たとえば、描画メソッド内で何かを描画するために10,000個のポリゴンを作成する必要がある場合、コンテナを介してすべてのポリゴンを作成すると、パフォーマンスが大幅に低下する可能性があります。
    

    ご注意
    一部のコンテナは、新しいキーワードを使用してオブジェクトインスタンスを作成するのとほぼ同じ速さでオブジェクトインスタンスを解決できます。 しかし、いずれにしても、ループ内の多数のオブジェクトのコンテナーを介した解決は、真剣に正当化される必要があります。
    

  • 深い依存関係が多数ある場合、それらを解決するために必要な時間が大幅に増加する可能性があります。
  • コンポーネントに依存関係がない場合、またはコンポーネント自体が他のタイプの依存関係でない場合、コンテナを作成するときに使用したり、コンテナに配置したりすることはそれぞれ意味がありません。
  • コンポーネントに、その不可欠な部分である単一の依存関係セットがあり、変更されない場合、作成時にコンテナを使用する意味がない場合があります。 ただし、この場合、テストは複雑になる可能性があります。
  
  
• コンポーネントをシングルトンとして登録するか、インスタンスとして登録するかを検討します。
  
  • コンポーネントが、ロギングサービスなどの単一のリソースマネージャーとして機能するグローバルサービスである場合、シングルトンとして登録できます。
  • コンポーネントが多数のコンシューマーに一般状態へのアクセスを許可する場合、シングルトンとして登録できます。
  • オブジェクトがデプロイされるたびに新しいインスタンスを作成する必要がある場合、シングルトンとして登録できません。 たとえば、各ビューには、おそらくビューモデルの新しいインスタンスが必要です。
  
  
• コンテナをコードで構成するか、構成ファイルを使用して構成するかを検討します。
  
  • すべてのサービスを一元管理する場合は、構成ファイルを使用します。
  • 状況に応じてさまざまなサービスを登録する場合は、コードでコンテナを構成します。
  • モジュールレベルのサービスがある場合は、モジュールがロードされたときにのみ登録されるように、コードを使用してコンテナを構成します。
  
  

ご注意
MEFなどの一部のコンテナは、構成ファイルを介して構成できず、コードで構成する必要があります。

基本シナリオ

コンテナは、登録と許可という2つの主な目的に使用されます。

登録

依存関係をオブジェクトに注入する前に、依存関係の種類をコンテナに登録する必要があります。 通常、型を登録するには、コンテナにインターフェイスを渡し、そのインターフェイスを実装する特定の型を渡します。 まず最初に、タイプとオブジェクトを登録する方法が2つあります：コード内で、または構成ファイルを使用して。 実装の詳細は、コンテナによって異なる場合があります。

通常、コードとコンテナーに型とオブジェクトを登録するには、2つの方法があります。

• タイプを登録するか、あるタイプを別のタイプにマップできます。 適切なタイミングで、コンテナは指定したタイプのインスタンスを作成します。
• オブジェクトの既存のインスタンスをシングルトンとして登録できます。 コンテナは、既存のオブジェクトへのリンクを返します。

UnityContainerでのタイプの登録

初期化中に、型はビューやサービスなどの他の型を登録する場合があります。 登録により、コンテナによって依存関係を解決し、他のタイプで利用できるようになります。 これを行うには、モジュールコンストラクターでコンテナーを実装する必要があります。 次のコードは、 Commanding QuickStartのOrderModuleが、シングルトンなどの初期化時にリポジトリのタイプを登録する方法を示しています。

 public class OrderModule : IModule { public void Initialize() { this.container.RegisterType<IOrdersRepository, OrdersRepository>(new ContainerControlledLifetimeManager()); ... } ... } 

使用しているコンテナに応じて、構成ファイルを介してコード外で登録を行うこともできます。 例については、第4章「 モジュール式アプリケーション開発 」の「構成ファイルを使用したモジュールの登録」を参照してください。

タイプをMEFコンテナに登録する

コンテナにタイプを登録するために、MEFは属性ベースのシステムを使用します。 その結果、タイプ登録をコンテナに追加するのは非常に簡単です。このためには、次の例に示すように、コンテナに登録するタイプに[Export]属性を追加する必要があります。

 [Export(typeof(ILoggerFacade))] public class CallbackLogger: ILoggerFacade { ... } 

MEFのもう1つの使用例は、クラスをインスタンス化し、その特定のインスタンスをコンテナに登録することです。 MEF QuickStartを使用したSilverlight for ModularityのQuickStartBootstrapperは、 ConfigureContainerメソッドでこの例を示しています。

 protected override void ConfigureContainer() { base.ConfigureContainer(); //    CallbackLogger,     , //    ,     (),   . this.Container.ComposeExportedValue<CallbackLogger>(this.callbackLogger); } 

ご注意
MEFをコンテナとして使用する場合、タイプを登録するために属性を使用することをお勧めします。

許可

タイプが登録されると、依存関係として解決または実装できます。 型が解決され、コンテナがこの型の新しいインスタンスを作成する必要がある場合、このインスタンスに依存関係を注入します。

一般に、型が解決されると、次の3つのいずれかが発生します。

• タイプが登録されていない場合、コンテナは例外をスローします。
  

  ご注意
  Unityを含む一部のコンテナでは、登録されていない特定のタイプを許可できます。

• タイプがシングルトンとして登録されている場合、コンテナはシングルトンのインスタンスを返します。 これが最初の呼び出しである場合、コンテナはインスタンスを作成し、将来の呼び出しのために保存できます。
• タイプがシングルトンとして登録されていない場合、コンテナは新しいインスタンスを返します。
  

  ご注意
  デフォルトでは、MEFに登録されているタイプはシングルトンであり、コンテナはオブジェクトへの参照を保存します。 Unityでは、デフォルトでオブジェクトの新しいインスタンスが返され、コンテナーはそれらへの参照を保存しません。

ユニティ解像度

Commanding QuickStartの次のコード例は、 OrdersEditorViewおよびOrdersToolBarコンテナーからどのように解決され、それぞれの領域にバインドされるかを示しています。

 public class OrderModule : IModule { public void Initialize() { this.container.RegisterType<IOrdersRepository, OrdersRepository>(new ContainerControlledLifetimeManager()); //   Orders Editor    . this.regionManager.RegisterViewWithRegion("MainRegion", () =>; this.container.Resolve<OrdersEditorView>()); //   Orders Toolbar    . this.regionManager.RegisterViewWithRegion("GlobalCommandsRegion", () => this.container.Resolve<OrdersToolBar>()); } ... } 

OrdersEditorPresentationModelコンストラクターには、解決時に導入される次の依存関係（順序リポジトリと順序コマンドプロキシ）が含まれます。

 public OrdersEditorPresentationModel(IOrdersRepository ordersRepository, OrdersCommandProxy commandProxy) { this.ordersRepository = ordersRepository; this.commandProxy = commandProxy; //     . this.PopulateOrders(); //  CollectionView    . #if SILVERLIGHT this.Orders = new PagedCollectionView( _orders ); #else this.Orders = new ListCollectionView( _orders ); #endif //   . this.Orders.CurrentChanged += SelectedOrderChanged; this.Orders.MoveCurrentTo(null); } 

前の例で示したように、コンストラクターに埋め込むことに加えて、Unityはプロパティに依存関係を埋め込むこともできます。 [Dependency]属性が適用されるプロパティは、オブジェクトが解決されると自動的に解決され、実装されます。 プロパティがOptionalDependency属性でマークされている場合、依存関係を解決できない場合、プロパティはnull設定され、例外はスローされません。

MEFのインスタンスの解決

MEF QuickStartを使用したSilverlight for Modularityの Bootstrapperがシェルインスタンスを取得する方法を次のコード例に示します。 特定のタイプを要求する代わりに、コードはインターフェースのインスタンスを要求できます。

 protected override DependencyObject CreateShell() { return this.Container.GetExportedValue<Shell>(); } 

ILoggerFacadeおよびIModuleTrackerを実装するMEF QuickStartを使用した 、 ModuleAからModularity for Silverlightへの次のコード例に示すように、MEFが許可するクラスでは、コンストラクターへの注入も使用できます。

 [ImportingConstructor] public ModuleA(ILoggerFacade logger, IModuleTracker moduleTracker) { if (logger == null) { throw new ArgumentNullException("logger"); } if (moduleTracker == null) { throw new ArgumentNullException("moduleTracker"); } this.logger = logger; this.moduleTracker = moduleTracker; this.moduleTracker.RecordModuleConstructed(WellKnownModuleNames.ModuleA); } 

または、埋め込みILoggerFacadeインスタンスを持つMEF QuickStartを使用したModularity for Silverlightの ModuleTrackerクラスに示すように、プロパティインジェクションを使用できます。

 [Export(typeof(IModuleTracker))] public class ModuleTracker : IModuleTracker { // -  Silverlight/MEF,    . [Import] public ILoggerFacade Logger; } 

ご注意
Silverlightでは、インポートされたプロパティとフィールドはパブリックである必要があります。

Prismで依存関係注入コンテナーとサービスを使用する

依存性注入コンテナは、コンポーネント間の依存関係を満たすために使用されます。 これらの依存関係を満たすには、通常、登録と解決が必要です。 Prismライブラリは、UnityおよびMEFコンテナのサポートを提供しますが、それらには依存しません。 ライブラリはIServiceLocatorインターフェイスを介してコンテナにアクセスできるため、コンテナは簡単に交換できます。 これを行うには、 IServiceLocatorインターフェイスを実装する必要があります。 通常、コンテナを交換する場合は、独自のコンテナ固有のブートローダーも作成する必要があります。 IServiceLocatorインターフェイスIServiceLocator 、 Common Service Locator Libraryで定義されています。 これは、依存性注入コンテナーやサービスロケーターなどのIoC（制御の反転）コンテナーの抽象化を提供するためのオープンソースプロジェクトです。 このライブラリを使用する目的は、特定のコンテナ実装を提供せずに、IoCとサービスロケーションを使用することです。

Prismライブラリは、 UnityServiceLocatorAdapterとMefServiceLocatorAdapter提供します。 両方のアダプターはISeviceLocatorインターフェースを実装し、 ServiceLocatorImplBaseタイプを拡張します。 次の図は、クラス階層を示しています。



Prismライブラリは特定のコンテナを参照または依存しませんが、アプリケーションが非常に特定のDIコンテナを使用するのは一般的です。 これは、アプリケーションが特定のコンテナを参照するのが妥当であることを意味しますが、Prismライブラリはコンテナを直接参照しません。 たとえば、 Stock Trader RIアプリとQuickStartsのいくつかは、Unityをコンテナとして使用します。 他の例とクイックスタートはMEFを使用します。

IServiceLocator

次のコードは、 IServiceLocatorインターフェイスとそのメソッドを示しています。

 public interface IServiceLocator : IServiceProvider { object GetInstance(Type serviceType); object GetInstance(Type serviceType, string key); IEnumerable<object> GetAllInstances(Type serviceType); TService GetInstance<TService>(); TService GetInstance<TService>(string key); IEnumerable<TService> GetAllInstances<TService>(); } 

Service Locatorは、次のコードに示す拡張メソッドでPrismライブラリを補完します。 IServiceLocator 、許可ではなく登録にのみ使用されていることがわかります。

 public static class ServiceLocatorExtensions { public static object TryResolve(this IServiceLocator locator, Type type) { try { return locator.GetInstance(type); } catch (ActivationException) { return null; } } public static T TryResolve<T>(this IServiceLocator locator) where T: class { return locator.TryResolve(typeof(T)) as T; } } 

UnityコンテナがサポートしないTryResolve拡張TryResolve 、登録された場合に許可する必要がある型のインスタンスを返しnull 。そうでない場合はnull返しnull 。

ModuleInitializerは、次のコード例に示すように、 IServiceLocatorを使用して、読み込み中にモジュールの依存関係を解決します。

 IModule moduleInstance = null; try { moduleInstance = this.CreateModule(moduleInfo); moduleInstance.Initialize(); } ... 

 protected virtual IModule CreateModule(string typeName) { Type moduleType = Type.GetType(typeName); if (moduleType == null) { throw new ModuleInitializeException(string.Format(CultureInfo.CurrentCulture, Properties.Resources.FailedToGetType, typeName)); } return (IModule)this.serviceLocator.GetInstance(moduleType); } 

IServiceLocatorの使用に関する考慮事項

IServiceLocator 、汎用コンテナとして使用することを意図したものでIServiceLocatorません。 コンテナにはさまざまな使用方法があり、多くの場合、コンテナの選択に影響します。 これを念頭に置いて、 Stock Trader RIはIServiceLocatorを使用する代わりに、依存関係注入コンテナーを直接使用します。 これは、アプリケーションを開発するときに推奨されるアプローチです。

次の状況では、 IServiceLocatorの使用が適切です。

• あなたは、複数のコンテナをサポートする必要があるサードパーティのサービスを開発している独立系ソフトウェアベンダー（ISV）です。
• 異なるコンテナを使用する組織で使用されるサービスを開発しています。

追加情報

DIコンテナーに関連する情報については、以下を参照してください。

• MSDNの「Unity Application Block」： http : //www.msdn.com/unity
• CodePlexのUnityコミュニティサイト： http : //www.codeplex.com/unity
• MSDNの「Managed Extensibility Framework Overview」： http : //msdn.microsoft.com/en-us/library/dd460648.aspx
• CodePlexのMEFコミュニティサイト： http : //mef.codeplex.com/
• Martin FowlerのWebサイトの「コントロールコンテナの反転と依存性注入パターン」： http : //www.martinfowler.com/articles/injection.html
• MSDNマガジンの 「Design Patterns：Dependency Injection」： http : //msdn.microsoft.com/en-us/magazine/cc163739.aspx
• MSDNマガジンの 「緩め：より柔軟なアプリのためにソフトウェアの依存関係を調整する」： http : //msdn.microsoft.com/en-us/magazine/cc337885.aspx
• Castle Project： http : //www.castleproject.org/container/index.html
• StructureMap： http : //structurcodeap.sourceforge.net/Default.htm
• Spring.NET：http://www.springframework.net/