2

現在、選択した IoC コンテナーとして Autofac を使用しています。再利用可能なアセンブリ内のすべてのアプリケーション コードは、できるだけクリーンに保つ必要があるため、コア アプリケーションで Autofac に直接依存することは望ましくありません。Autofac が許可されている唯一の場所は、コンポーネントが登録され、接続されているコンポジション ルート/ブートストラップです。アプリケーションは依存性注入に依存して、必要なオブジェクト グラフを作成します。

コア アプリケーション コンテナーに依存しないようにしているため、コア アプリケーションで などの Autofac 関係タイプを使用できないことを意味しOwnedます。

を実装するコンポーネントを返すファクトリを作成したいと思いますIDisposable。Autofac は破棄可能なオブジェクトを追跡するため、有効期間スコープを使用して定義済みの作業単位を作成する必要があると考えています。コンポーネントは、スコープ外になると破棄されます。

Autofac のドキュメントによると、これは に依存することで実現できますが、Func<Owned<T>>前述のようにOwned、Autofac 型であるため、 に依存することはできません。このページの一番下には、

Autofac のカスタム リレーションシップ タイプは、アプリケーションを Autofac により緊密にバインドすることを強制しません。これらは、他のコンポーネントの作成方法と一貫性のあるコンテナー構成のプログラミング モデルを提供します (構成を一元化する可能性のある多くの特定のコンテナー拡張ポイントと API を知る必要があるのとは対照的です)。

たとえば、コア モデルでカスタム ITaskFactory を作成することはできますが、Func<Owned<T>>それが望ましいかどうかに基づいて AutofacTaskFactory 実装を提供できます。

実装する必要があると思うのはこの実装ですがITaskFactory、例が見つかりません。

誰かがそのような例を提供できれば、とても感謝しています。

4

1 に答える 1

1

おそらく、これの最良の「実世界」の例は、AutofacMVC統合メカニズムです。裏で使用することはありませんFunc<Owned<T>>が、Autofacに固有ではないメカニズムを実装して、裏でAutofacと通信する方法を示しています。

MVCの場合、System.Web.Mvc.IDependencyResolverはインターフェイスであり、Autofac.Integration.Mvc.AutofacDependencyResolverは実装です。ASP.NET MVCがサービスを要求すると、からサービスを取得します。これによりSystem.Web.Mvc.DependencyResolver.Current、が返されますIDependencyResolver。アプリの起動時に、そのシングルトンはAutofac実装に設定されます。

同じ原則がカスタムファクトリにも当てはまります。IDependencyResolver返されるタイプに固有ではありませんが(それはただのことGetService<T>()です)、タイプ固有のファクトリインターフェイスを同じように簡単に作成できます。

于 2013-01-14T17:00:23.507 に答える