inversion-of-control - Unity フレームワークは制御の反転に適していますか?

Question

少し前からIoCを使っているのですが、MicrosoftのUnityフレームワーク（正式名称「Unity Application Block」）を使うべきか迷っています。誰もそれを使用した経験がありますか? そのため、IoC コンテナー コードをプロジェクトからプロジェクトにコピーしてきましたが、標準的なものを使用する方がよいと思います。IoC は、コンポーネント ベースのアプリケーションを疎結合して変更可能に保つという点で大きな違いを生むことができると思いますが、私は決して IoC の専門家ではないので、依存関係として隅に追いやられるフレームワークに切り替えるのは緊張しています。いつか立ち去りたいと思うでしょう。

Answer 1

Unity を実際に問題なく使用しています。一部の ALT.NET タイプの人々が Unity に対して警告していることは知っていますが、それは MS P&P チームがブロートウェアを作成してきた歴史があるためだと思います。Unity はまだ肥大化した IMO ではなく、うまく機能します。

Answer 2

Unity フレームワークを調べてみましたが、私のニーズには少し「大きすぎる」ことがわかりました (いいえ、それを実際に定量化することはできません。私がこれまでに使用してきた他のフレームワークよりもはるかに多くの知識が必要なようでした)。で遊んでいます...これは少し前のことなので、Unity が開発/改良されて変更された可能性があります)。

私の現在の IoC/依存性注入フレームワークはNinjectです。速くて速く、約 2 時間でチュートリアルを読んで (約 10 分)、既存のプロジェクトで使用することができました。

依存性注入を行うクリーンな方法を探している場合は、チェックすることを強くお勧めします。

Answer 3

Compositeアプリブロックの後継であるCompositeWPF（別名Prism）で遊んだことがあります。私の経験から、Unityは以前のバージョンのObjectBuilderと比較してはるかにうまく機能します。ただし、IoCフレームワークを評価し、ニーズに適したフレームワークを選択するのはあなた次第です。

Unityのチュートリアルとサンプル

UnityIoCスクリーンキャスト

Answer 4

それと全体のコンセプトに自信が持てるまで、あなたが知っているものに固執することをお勧めします. その後、ニーズを満たすフレームワークを選択するためのより良い判断が得られます。