3

私は今1年以上、StructureMapを使用しています。そして、私はこのIoC用のラッパーをお持ちですか?

class IoC { 
    public static T GetInstance<T>() 
    { 
     return (T)GetInstance(typeof(T)); 
    } 
    public static IEnumerable<T> GetAllInstances<T>() 
    { 
     return ObjectFactory.GetAllInstances<T>(); 
    } 

    public static IEnumerable GetAllInstances(Type type) 
    { 
     return ObjectFactory.GetAllInstances(type); 
    } 

    public static object GetInstance(Type type) 
    { 
     return ObjectFactory.GetInstance(type); 
    } 

    public static void Inject<T>(T obj) 
    { 
     ObjectFactory.Inject(obj); 
    } 
} 

のように見えたのIoCと呼ばれるラッパークラスを持っていたすべてのこの時間は、私はラインの下のいくつかの点でIoCコンテナを変更したい場合がありますことを想定ラッパーを追加しました。この時点で、私はこれが悪いと思っています。その理由の1つは、私のコードでObjectFactoryを使用して他の面白いことをすることができないことです。このラッパーを使用する必要があります。もう一つは:私たちのコードは、実際にDependencyInjectionコンテナから独立している必要はありません。

このアプローチを使用する際の賛否両論は何ですか?

+0

[Mark Seemann](http://blog.ploeh.dk/)は、このようなラッパーを「適合コンテナ」と呼びます。彼は最近、[これについてのブログ記事](http://blog.ploeh。dk/2014/05/19/conforming-container /)、彼はこれを明白に反パターンと呼んでいる。 – Steven

答えて

6

このため、Common Service Locatorプロジェクトが開発されました。これはDIフレームワークの抽象であり、あなたのIoCクラスのようなインターフェイスを定義します。私はさらにSimple Service Locatorライブラリを開発しました。共通サービス・ロケーター・インターフェースの直接実装であるDIライブラリー。

この意味では、DIフレームワークよりも抽象概念を持つのは奇妙ではありません。しかし、Dependency Injectionを正しく(そして完全に)行うには、アプリケーションの設計をそれに応じて調整し、アプリケーションルートにコンテナを設定し、アプリケーションが組み立てられた場所を1つだけにすることが望ましいGetInstanceが呼び出されます)。 ASP.NET MVCアプリケーションの場合、これはControllerFactoryになります。 ASP.NET WebFormsアプリケーションでは、通常、PageHandlerFactoryを上書きする必要があります。

これらのルールでプレイすると、そのような抽象化を使用する理由はありません。なぜなら、とにかくアプリケーションの単一の場所でコンテナを呼び出すだけだからです。しかし、それが実現不可能な場合は、Common Service Locatorまたは自分の抽象化のいずれかを使用することができます。

しかし、多くの問題が発生し、一般的にはis seen as an anti-patternが原因でコードがIoCライブラリの抽象化に依存するようにする前に一歩前に戻ってください。コード内からコンテナにコールバックする:

  • コードをテストするのがずっと難しくなります。
  • コードを読みやすく保守しにくくする代わりに、依存関係を隠します。
  • コンパイル時のサポートを無効にします。
  • 依存関係グラフをツールで検証することを禁止します。
+0

外部依存関係を包むラッパーを使用するのは理にかなっていますが、人がIoCコンテナを切り替える実際のインスタンスが存在するかどうかはわかりません。 –

1

プロは、IOCコンテナを痛みを伴わずにスワップすることができます。 IOCコンテナに特有の機能を失うということがあります。 MVCタービンはこのアプローチを使用します。どのようにロケータを処理するかを調べるには、ソースを見てください。 http://mvcturbine.codeplex.com/

1

あなたはライブラリの多くは、これらのライブラリの上に構築されたアプリケーションの多くを持っている場合は、それらのアプリケーションのすべてにわたって重複しますIoCの登録コードが大量になってしまいます。

コンテナに登録する責任は各ライブラリに持たせることができますが、特定のIoC実装について知っておく必要があります。または、IoCラッパーを提案して作成し、IoCラッパーを使用して自分自身のライブラリーを登録する責任を持つようにすることもできます。

関連する問題