38

ユーザー インターフェイスの依存性注入ツールに Microsoft Unity を使用することを考えています。

私たちの中間層はすでにキャッスル ウィンザーを使用していますが、Microsoft を使い続ける必要があると考えています。

最高の依存性注入ツールとは何かについて考えている人はいますか?

4

9 に答える 9

61

最近、これらのうち6つ（Windsor、Unity、Spring.Net、Autofac、Ninject、StructureMap）の使用を急増させたので、それぞれの簡単な要約、選択基準、および最終的な選択を提供できます。

注：私たちのチームの1人が.NetポートはJavaバージョンからかなり貧弱であると考えていたため、PicoContainer.Netは調べませんでした。UnityはObjectBuilder2の上に構築されており、デフォルトで優れた選択肢であると考えられていたため、ObjectBuilderについても検討しませんでした。

まず、多かれ少なかれそれらのすべてが非常に似ていると言うことができます、そしてそれは本当にあなたにとって本当に最もうまくいくものとあなたの特定の要件に帰着します。要件は次のとおりです。

要件

  • コンストラクターベースのインジェクション（プロパティ、フィールド、またはメソッドのインジェクションは使用しない予定です）
  • プログラム可能な構成（XMLではない）
  • コンテナ階層（コンポーネントのライフタイムスコープをコンテナに暗黙的にバインドするために、アプリケーションごと、リクエストごと、セッションごとに1つ）
  • コンポーネントのライフタイム管理（トランジェント/シングルトンなどのより詳細なスコープの場合）
  • インターフェイスからタイプまたは具象インスタンスへの注入（例：ILogger -> typeof(FileLogger)またはILogger -> new FileLogger()）
  • 高度なコンポーネント作成/初期化前後の「クレアトンイベントメカニズム」
  • IDisposableコンテナ分解時のコンポーネントの正しい廃棄

  • 十分に文書化された情報および/またはオンライン情報がすぐに利用可能

    注：パフォーマンスは要件でしたが、レビューされたすべてのコンテナーはこのベンチマークに従って類似しているように見えたため、選択には考慮されませんでした

テスト

各コンテナーは、一般的なAsp.Net Webフォームプロジェクトで使用されました（これがターゲットアプリケーションタイプであったため）。それぞれがベースページ/ベースコントロールから継承する単一のシンプルなユーザーコントロールを持つ単一のシンプルなページを使用しました。BasePage「リクエストごと」のスコープコンテナには1つのコンテナを使用し、「アプリケーション」スコープにはglobal.asaxに1つのコンテナを使用し、両方のコンテナから依存関係を解決できるように、それらをチェーン化しようとしました。

各Webアプリケーションは、マルチレベルの依存関係、スコープタイプ（シングルトン/トランジェント）、およびマネージドクラスとアンマネージドクラス（IDisposable必須）をシミュレートする、考案されたドメインオブジェクトのセットを共有しました。「トップレベル」の依存関係コンポーネントは、のメソッドから手動で挿入されましたBasePage。

結果

ウィンザー-すべての基準を満たし、優れた病歴、ブロガーコミュニティ、オンラインドキュメントがあります。使いやすく、おそらく事実上の選択です。Factory機能による高度なコンポーネント作成。個別に作成されたコンテナのチェーンも許可されました。

Spring.Net-冗長で役に立たないドキュメントであり、プログラム可能な構成が自明ではない/簡単です。ジェネリックをサポートしていませんでした。選ばれなかった

Ninject-使いやすく、明確なドキュメントがあります。コンテナ階層を除くすべての要件を満たす強力な機能セットであるため、残念ながら選択されませんでした。

StructureMap-十分に文書化されていませんが、すべての要件を満たす非常に高度な機能セットがありましたが、forループを使用して一緒にハッキングされる可能性はありますが、コンテナー階層の組み込みメカニズムはありませんでした 。ラムダ式の流暢なインターフェイスは少し上に見えました最初は複雑ですが、カプセル化することもできます。

Unity-十分に文書化され、使いやすく、すべての選択基準を満たし、必要な作成前/作成後のイベントメカニズムを追加するための簡単な拡張メカニズムを備えています。子コンテナは、親コンテナから作成する必要がありました。

Autofac-ラムダ式の設定は少し複雑に見えますが、十分に文書化されており、比較的使いやすいですが、ここでも簡単にカプセル化できます。コンポーネントのスコープは「タグ付け」メカニズムによって実現され、すべてのコンポーネントは、少し不便だったビルダーを使用して事前に構成されます。子コンテナは親から作成され、「タグ」からコンポーネントが割り当てられました。ジェネリック注射を許可しました。

結論

最終的に選択したのはWindsorとUnityのどちらかでしたが、今回は使いやすさ、ドキュメント、拡張システム、および「本番」ステータスであるため、Unityを選択しました。

于 2008-12-06T15:37:46.053 に答える
12

.NET IoC コンテナーを比較した優れた記事を次に示します。 http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/

于 2008-10-03T20:36:06.680 に答える
12

システムが IoC/DI を念頭に置いて設計されている場合、1 つのコンテナーに固執することはそれほど重要ではありません。適切なアプローチをとれば、後で IoC ライブラリを簡単に変更できます。

そしてもちろん、コンテナーは、広く使用されている一般的なシナリオ (ライフサイクル管理、適切なコンテナーの入れ子、XML とコードの構成、傍受、迅速な解決) をサポートするのに十分な柔軟性を提供する必要があります。

Castle (広く使用されており、多くの統合ライブラリがある) と Autofac (軽量で高速で、適切なコンテナーのネストがありますが、それほど広く使用されていません) のどちらかを選択することをお勧めします。

Hanselman によるIoC コンテナーの包括的なリストがあります。

PS: Unity を使用したくない場合

于 2008-09-30T06:00:01.500 に答える
5

1年前にAutofacを使い始めて以来、振り返っていません..

于 2009-07-15T22:03:49.973 に答える
4

私は Autofac のファンですが、Windsor と Unity はどちらもうまく機能します (ただし、Windsor は Unity よりも優れており、コードの帰属を示す必要はありません)。ただし、システム内の単一のコンテナーに固執することには、非技術的な理由がたくさんあります。

于 2008-09-29T14:33:54.783 に答える
2

私はManaged Extensibility Frameworkを使用してきましたが、非常に簡単に操作できることがわかりました。.NET 4に統合されました。

于 2010-02-02T20:58:02.477 に答える
2

機能するものを使用してください。ほとんどが独自の機能を備えており、ほとんどすべてが Unity よりも機能が豊富です。団結さえあれば、きっと使えます。

Microsoft からのものだからという理由だけで Microsoft の unity を使用することは、決定を下すための貧弱な方法です。必要なものとその理由を考えて、ニーズに合ったものを選択してください。

ただし、可能であれば、単一のコンテナーに固執するという考えを支持します。

于 2008-09-29T14:36:48.927 に答える
0

可能なIoCコンテナソリューションの1つで利用される特定のサブテクノロジーに対する経験と個人的な好みがない限り、それらはすべてうまく機能し、特にそれを際立たせる「キラー機能」を備えたものは見当たりません。他の人から。Unityは、すでにP＆P EnterpriseLibrary4.xを利用しているソリューションにおそらく最適です...

于 2008-11-15T22:11:49.947 に答える
0

IoC Container Benchmark-パフォーマンス比較には、20以上の製品のパフォーマンスと機能の比較表があり、それらを最新の状態に保ちます。

記事からの結論：

SimpleInjector、Hiro、Funq、Munq、Dynamoは最高のパフォーマンスを提供し、非常に高速です。それらを試してみてください！

特にシンプルなインジェクターは良い選択のようです。非常に高速で、優れたドキュメントがあり、インターセプトや一般的なデコレータなどの高度なシナリオもサポートしています。

于 2013-02-22T06:03:23.297 に答える