UIからIOCコンテナの設定を抽象化する必要がありますか？

Question

私たちのチームは、システムの「API」として構築されて強く定義されたアプリケーションサービス層を有するDDDアプリを構築してきました。ドメインとインフラストラクチャからすべてのものを集めて一般的なタスクを実行します。入力/出力としてDTOだけを使用するので、ドメインはこのレイヤーを超えて公開されません。

今、私たちは、ミックスに依存性注入コンテナを追加したいと我々はいくつかの厳しい選択に直面しています。アプリケーションサービスを使用して作業を行う2つのクライアントアプリケーションMVC 2アプリとWindowsサービスアプリがあります。従来、依存性注入作業を行うためのすべての設定コードは、mvcプロジェクトのglobal.asaxファイルに格納されています。問題は、IOC登録コードがWindowsサービスで複製され、そのプラットフォーム用にわずかに変更されてしまうことです。

私が持っている問題は、DIを登録するにはどのようなドメインおよびインフラストラクチャ層への参照を持っているか、また、クライアントアプリを必要としているかを知るために、クライアントアプリを必要とすることです。アプリサービス層を持つアイデアの全体は、クライアントが知っていて話すべき唯一のものだということでした。私の提案された解決策は、クライアントが一度呼ぶだろうし、それが必要なものを知っているので、それはDIコンテナを設定するだろうと私のアプリサービス層で「依存関係サービス」を作成することでした。また、クライアントアプリケーションが独自の依存関係を登録できるようにするメソッドもあります。たとえば、MVCプロジェクトはコントローラファクトリを登録し、Windowsサービスはそのスタートアップクラスを登録します。私はこれが珍しいのか、私がこの考え方で間違った道を歩んでいるのかを知りたかったのです。他の誰かが前にこの問題を遭遇しましたか？

Answer 1

私はDDDまたはドメインモデルプロジェクトに設定クラスを入れて、UI構成クラスを呼び出します。

public static class IoCConfigurator() 
{ 
    public static void Initialize() 
    { 
     // your code here 
    } 
} 

UIでは、Initialize（）メソッドのみを呼び出す必要があります。 MVC Global.asaxやWindowsサービスアプリでも使用できます。コードの重複はありません。

非常にうまく動作します。

Answer 2

猫を肌にはさまざまな方法があります。しかし、あなたは間違ったアプローチをしているようです。アプリケーションのエントリポイント（Global.asaxまたはProgram.cs）は、IoCコンテナで構成するコンポーネントを選択する場所にする必要があります。一方、あなたのサービスは、一般的にIoCの設定知識が組み込まれているべきではありません。私の推測では、あなたはすでにこの原則に従っていますが、繰り返しの設定のために再検査しています。

前述のように、コードを繰り返しなくても実現できるようにするために、多くのIoCコンテナは、関連コンポーネントのセットの構成をカプセル化するモジュール化構成を提供します。 Autofac（およびNinject IIRC）では、これらは「モジュール」と呼ばれます - http://code.google.com/p/autofac/wiki/StructuringWithModules。キャッスルウィンザーはそれらを「インストーラ」と呼び、StructureMapはそれらを「レジストリ」と呼びます。

構成をモジュールに分解することによって、アプリケーションの起動方法の構成コードの量が削減されます。 ServiceProcessModule

CoreModuleが共有されているコンポーネントの構成が含まれており、中に同じ動作です

• CoreModule
• WebModule
• ：あなたの例では、単純化として、次の3つのモジュールを作成することができますそれぞれの実行環境。

  WebModuleとServiceProcessModuleには、それらの環境に固有のコンポーネントの登録と、ホストによって異なる構成の共有コンポーネントの特殊な構成が含まれます。サービスプロセスは非常に似ていますが、ServiceProcessModuleためWebModuleを代入するであろうが

  foo.RegisterModule<CoreModule>(); 
  foo.RegisterModule<WebModule>(); 
  // Resolve root component, run app 
  

  ：

  あなたのウェブアプリの起動は、その後のようなものになるだろう。

  このような構成のスタイルは、条件付きコードによる静的な初期化方法と比較すると、多くのアプリケーションのエントリポイントやコンポーネントの多くのサブシステムの方がはるかに優れています。

  これが役に立ちます。 ニック