調べる価値のある C#/.NET 依存性注入フレームワークはどれですか? そして、それらの複雑さと速度について何と言えますか。
12 に答える
編集(作成者によるものではありません): https ://github.com/quozd/awesome-dotnet/blob/master/README.md#iocで利用可能なIoCフレームワークの包括的なリストがあります:
- Castle Windsor -Castle Windsorは、.NETおよびSilverlightで利用可能な、最高の成熟した制御の反転コンテナです。
- Unity-コンストラクター、プロパティ、メソッド呼び出しインジェクションをサポートする軽量の拡張可能な依存性注入コンテナー
- Autofac-中毒性のある.NETIoCコンテナ
- DryIoc-シンプルで高速なすべての機能を備えたIoCコンテナ。
- Ninject-.NET依存関係インジェクターの忍者
- Spring.Net-Spring.NETは、エンタープライズ.NETアプリケーションの構築を容易にするオープンソースアプリケーションフレームワークです。
- Lamar -ASP.NETCoreおよびその他の.NETサーバー側アプリケーション内での使用に合わせて大幅に最適化された高速IoCコンテナー。
- LightInject-超軽量のIoCコンテナ
- Simple Injector -Simple Injectorは、Silverlight 4以降、Windows Phone 8、ユニバーサルアプリおよびMonoを含むWindows 8をサポートする、.NET 4以降用の使いやすい依存性注入(DI)ライブラリです。
- Microsoft.Extensions.DependencyInjection -ASP.NETCoreアプリケーションのデフォルトのIoCコンテナー。
- Scrutor -Microsoft.Extensions.DependencyInjectionのアセンブリスキャン拡張機能。
- VS MEF -Visual Studioで使用されるマネージドエクステンシビリティフレームワーク(MEF)の実装。
- TinyIoC-小さなプロジェクト、ライブラリ、初心者向けの使いやすく、手間のかからない制御の反転。
- Stashbox-.NETベースのソリューション向けの軽量で高速かつポータブルな依存性注入フレームワーク。
元の答えは次のとおりです。
ここでは少し気難しいかもしれませんが、DI(依存性注入)はプログラミングパターンであり、IoC(制御の反転)フレームワークによって促進されますが、必須ではないことに注意することが重要です。IoCフレームワークは、DIをはるかに簡単にし、DIに加えて他の多くの利点を提供します。
そうは言っても、それがあなたが求めていたものだと確信しています。IoCフレームワークについて; 私はSpring.NetとCastleWindsorをよく使用していましたが、背後にある本当の苦痛は、あなたが書かなければならなかった厄介なXML構成のすべてでした!それらはほとんどすべてこのように動いているので、私は昨年かそこらでStructureMapを使用しており、強く型付けされたジェネリックとレジストリを使用する流暢な構成に移行したため、IoCを使用する際の私の苦痛の障壁はゼロ以下!IoC構成がコンパイル時にチェックされ(ほとんどの場合)、StructureMapとその速度に満足していることを知って、私は絶対的なキックを得ることができます。他の人は実行時に遅いとは言いませんが、セットアップがより難しく、フラストレーションがその日を勝ち取ることがよくありました。
アップデート
私は最新のプロジェクトでNinjectを使用してきましたが、使用することは絶対的な喜びです。ここでは言葉が少し失敗しますが、(英国で言うように)このフレームワークは「犬」です。すぐに立ち上げて実行したいグリーンフィールドプロジェクトには、これを強くお勧めします。JustinEtheredgeによる素晴らしいNinjectスクリーンキャストのセットから必要なものをすべて入手しました。Ninjectを既存のコードに後付けすることが問題になることはまったくわかりませんが、私の経験では、 StructureMapについても同じことが言えます。これら2つの間で今後は難しい選択になるでしょうが、私は停滞よりもむしろ競争をしたいと思っており、そこにはかなりの量の健全な競争があります。
他のIoCスクリーンキャストもここDimecastsで見つけることができます。
それぞれに長所と短所があるため、探しているものによって異なります。
Spring.NET
Java の世界から Spring に由来するため、最も成熟しています。Spring には、Web、Windows などをサポートするように拡張するフレームワーク ライブラリの非常に豊富なセットがあります。Castle Windsor
.NET プラットフォームで最も広く使用されているものの 1 つであり、最大のエコシステムを持ち、高度に構成可能/拡張可能で、カスタム ライフタイム管理、AOP サポート、固有の NHibernate サポートを備え、万能の素晴らしいコンテナーです。Windsor は、モノレール、Active Record などを含むスタック全体の一部です。NHibernate 自体は、Windsor の上に構築されています。Structure Map
には、内部 DSL による非常に豊富できめ細かい構成があります。Autofac
は、固有の関数型プログラミングのサポートをすべて備えた新時代の IoC コンテナーです。また、ライフタイムの管理に関して、他のアプローチとは異なるアプローチを採用しています。Autofac はまだ非常に新しいものですが、IoC で可能なことの限界を押し上げています。Ninject
私は、より少ないほどより多くのアプローチで、より基本的なものであると聞いたことがあります(経験がないと聞いた)。- の最大の差別化要因は
Unity
、Microsoft (p&p) から提供され、サポートされていることです。Unity は非常に優れたパフォーマンスと優れたドキュメントを備えています。また、高度に構成可能です。キャッスル / ストラクチャー マップのすべての機能が備わっているわけではありません。
要約すると、それは本当にあなたにとって何が重要かによって異なります。どちらが適しているかを評価して確認することについては、他の人に同意します。良いことは、ゼリーを持たなければならないだけでなく、ドーナツの素晴らしい選択があることです.
オートファク。 https://github.com/autofac/Autofac本当に速くてかなり良いです。これは比較のリンクです(Ninjectがメモリリークの問題を修正した後に作成されました)。
http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html
ニンジェクトは素晴らしいです。とても速いようですが、比較はしていません。著者の Nate が Ninject と他の DI フレームワークとの比較を行い、Ninject の速度を改善する方法を探していることは知っています。
私が尊敬する多くの人が、StructureMap と CastleWindsor について良いことを言っているのを聞いたことがあります。これらは、私の考えでは、今注目すべき大きな 3 つです。
私はシンプルなインジェクターを使用しています:
Simple Injector は、ベスト プラクティスを使用してソリューションを成功へと導く、簡単で柔軟かつ高速な依存性注入ライブラリです。
私はキャッスルの大ファンです。IoC コンテナーのストーリーを超えて提供される機能も気に入っています。NHibernate、ロギング、AOP などを使用すると、非常に簡単になります。また、Boo の構成にBinsorを使用しており、そのおかげで言語としての Boo が本当に好きになりました。
最も単純な Spring.NET の例を機能させるために、1 日の大半を苦労して成功させることができませんでした。XML ファイルからアセンブリを見つける方法がわかりませんでした。一方、約 2 時間で、NUnit と MSTest の両方との統合のテストを含め、Ninject を機能させることができました。
Ninjectをお勧めします。信じられないほど高速で使いやすいですが、XML 構成が必要ない場合に限り、それ以外の場合は Windsor を使用する必要があります。
過去にSpring.NETを使用したことがあり、大きな成功を収めました。私たちがそれを使用したプロジェクトはそれ自体がかなり重いものでしたが、私はそれでかなりのオーバーヘッドに気づいたことはありません. ドキュメントを読んでセットアップするのに少し時間がかかりました。
Spring.Netは非常に堅実ですが、ドキュメントを読み進めるのに少し時間がかかりました。Autofacは優れており、.Net 2.0はサポートされていますが、コンパイルするにはVS 2008が必要です。そうでない場合は、コマンドラインを使用してアプリをビルドします。
Ninject から始めるのが良いと思います。これは新しく、多くの微調整が考慮されており、非常に高速です。開発者の Nate は、本当に素晴らしいサイトと素晴らしいサポートを提供しています。
C# の優れた点は、それ以前に何年にもわたる Java 開発者が打ち負かしてきた道をたどっていることです。したがって、私のアドバイスは、一般的に言えば、この性質のツールを探すときは、確実な Java の答えを探して、.NET への適応がまだあるかどうかを確認することです。
したがって、DI に関しては (非常に多くのオプションがあり、これは好みの問題です)、Spring.NETです。さらに、プロジェクトの背後にいる人々を調査することは常に賢明です。私は Eric Sink に敬意を払っているので、SourceGear 製品をソース管理に (使用する以外に) 提案することに何の問題もありません。マーク・ポラックが話しているのを見たことがありますが、何と言えばいいでしょうか。
結局のところ、DI フレームワークは数多くあります。最善の策は、そのうちのいくつかを使用していくつかのサンプル プロジェクトを実行し、十分な知識に基づいて選択することです。
幸運を!