Enterprise Library Unityと他のIoCコンテナー(Windsor、Spring.Net、Autofacなど)を使用する場合の長所と短所は何ですか?
Enterprise Library Unityと他のIoCコンテナー(Windsor、Spring.Net、Autofacなど)を使用する場合の長所と短所は何ですか?
回答:
ユーザーグループ向けのプレゼンテーションを準備しています。そのため、私はそれらの束を通り抜けました。つまり、AutoFac、MEF、Ninject、Spring.Net、StructureMap、Unity、Windsorです。
私は90%のケース(コンストラクターの注入、主に人々がIOCをとにかく使用するものです)を自慢したかったです。 ここで解決策を確認できます(VS2008)
そのため、いくつかの重要な違いがあります。
それぞれに他の機能もあります(AOPやより優れたギズモを備えているものもありますが、一般的にIOCに必要なのは、オブジェクトの作成と取得だけです)
注:CommonServiceLocatorを使用すると、さまざまなライブラリオブジェクトの取得の違いを無効にすることができます:http : //www.codeplex.com/CommonServiceLocator
これにより、コードによる方法とXML構成(app.config / web.config / custom.config)による2つの方法で初期化が行われます。一部は両方をサポートし、一部は1つのみをサポートします。注:IoCに役立つ属性を使用しているものもあります。
だからここに違いの私の評価があります:
コード初期化のみ(属性付き)。ラムダが好きだといいですね。初期化コードは次のようになります。
IKernel kernel = new StandardKernel(
new InlineModule(
x => x.Bind<ICustomerRepository>().To<CustomerRepository>(),
x => x.Bind<ICustomerService>().To<CustomerService>(),
x => x.Bind<Form1>().ToSelf()
));
初期化コードまたはXMLまたは属性。v2.5も非常にラムダです。全体として、これは私のお気に入りの1つです。StructureMapが属性を使用する方法に関するいくつかの非常に興味深いアイデア。
ObjectFactory.Initialize(x =>
{
x.UseDefaultStructureMapConfigFile = false;
x.ForRequestedType<ICustomerRepository>()
.TheDefaultIsConcreteType<CustomerRepository>()
.CacheBy(InstanceScope.Singleton);
x.ForRequestedType<ICustomerService>()
.TheDefaultIsConcreteType<CustomerService>()
.CacheBy(InstanceScope.Singleton);
x.ForConcreteType<Form1>();
});
初期化コードとXML。素晴らしいライブラリですが、XML構成はお尻の痛みです。マイクロソフトや高速道路のショップに最適なライブラリです。コードの初期化は簡単です:
container.RegisterType<ICustomerRepository, CustomerRepository>()
.RegisterType<ICustomerService, CustomerService>();
私の知る限りXMLに限ります。しかし、機能性については、Spring.Netは太陽の下でIoCが実行できるすべてのことを行います。しかし、ユニット化する唯一の方法はXMLを介するため、.netショップでは一般的に回避されています。ただし、.net / Javaショップの多くはSpring.Netを使用しています。これは、.netバージョンのSpring.NetとJava Springプロジェクトが類似しているためです。
注:Spring.NET CodeConfigの導入により、コードでの構成が可能になりました。
XMLとコード。Spring.Netと同様に、Windsorはあなたが望むことなら何でもします。ウィンザーはおそらく最も人気のあるIoCコンテナーの1つです。
IWindsorContainer container = new WindsorContainer();
container.AddComponentWithLifestyle<ICustomerRepository, CustomerRepository>("CustomerRepository", LifestyleType.Singleton);
container.AddComponentWithLifestyle<ICustomerService, CustomerService>("CustomerService",LifestyleType.Singleton);
container.AddComponent<Form1>("Form1");
XMLとコードの両方を混在させることができます(v1.2)。素敵なシンプルなIoCライブラリ。それほど大騒ぎせずに基本を行うようです。コンポーネントのローカルスコープと明確に定義されたライフタイム管理により、ネストされたコンテナをサポートします。
これを初期化する方法は次のとおりです。
var builder = new ContainerBuilder();
builder.Register<CustomerRepository>()
.As<ICustomerRepository>()
.ContainerScoped();
builder.Register<CustomerService>()
.As<ICustomerService>()
.ContainerScoped();
builder.Register<Form1>();
今日選択しなければならない場合:おそらく、StructureMapを使用します。これは、C#3.0言語機能を最大限にサポートし、初期化において最も柔軟性があります。
注:Chris Brandsmaは、元の回答をブログ投稿に変えました。
古いスレッドですが、これは私がunity vs spring.netと入力したときにGoogleが最初に表示したものなので...
Springは、XML設定が気に入らない場合にCodeConfigを実行します
http://www.springframework.net/codeconfig/doc-latest/reference/html/
また、Springは単なるDIコンテナーではありません。ドキュメントの「モジュール」セクションを見ると、DIコンテナーはそれが行う膨大なスタックの基礎となっています。
私は間違ってんだけど、私は、このリンクに記載されているようAutofac自体がXMLコンフィギュレーションをサポートしていると思うなら、私を修正:Autofac XML設定
注意すべき点の1つ:Ninjectは、(Webサイトによると)コンテキスト依存性注入をサポートする唯一のIoCコンテナーです。ただし、他のIoCコンテナの経験がないため、それが成り立つかどうかはわかりません。
2セントを足すために、StructureMapとUnityの両方を試しました。私は、StructureMapのドキュメントが不十分/誤解を招くように文書化されており、構成するのに苦労し、使用するのが不格好であることがわかりました。同様に、解決時にコンストラクター引数のオーバーライドなどのシナリオをサポートしていないようで、これが私にとって重要な使用ポイントでした。それで、私はそれを落として、Unityと一緒に行きました、そしてそれを約20分で私が望んだことをしました。
私はUnityを個人的に使用していますが、それはMicrosoftからのものだからです。私は1つの理由で決定を後悔します。それに対する反対の最大のものは、常に例外をスローさせる1つの大きな「バグ」を持っていることです。デバッグ中は例外を無視できます。ただし、例外をスローするのは負荷の高い操作であるため、実行するとアプリケーションの速度が大幅に低下します。たとえば、現在、コードの1つの場所でこの例外を「修正」しており、Unityの例外により、ページのレンダリング時間がさらに4秒長くなります。詳細と回避策については、以下を参照してください。