6

私はこの記事を読んで、Castle Windsor を使用して ASP.NET MVC3 に IDependencyResolver を実装せず、カスタム IControllerFactory に固執するというコメントを多くの人が見ました。基本的に私の質問は次のとおりです。

  1. Castle Windsor を使用して IDependencyResolver を実装しないでください。これは ASP.NET MVC 4でも当てはまりますか?

  2. 1の場合です。他の DI コンテナ (Unity、StructureMap) で Castle Windsor と同じ問題が発生することはありますか? 代替手段を使用できますか?

どうもありがとう

編集

Castle Windsor を実装に使用すべきではないように思えますIDependencyResolver。StructureMap などの他の DI コンテナーを使用することにしました。

4

3 に答える 3

2

IDependencyResolver の実装は可能であり、それほど難しくないことに同意します..そして、はい、プレイ中のライフスタイルによっては、明示的に Release() することは重要ではないかもしれません..そして、はい、キャッシュすることによって Release() を強制する方法があります他の微妙なトリックと同様に、どこかのインスタンス-これは解釈に任せるのが多く、問題があり、追跡するのが難しいと思います. Windsor がいつインスタンスを追跡するかを理解することは、必ずしもすぐには明らかではありません (つまり、コンポーネントに廃止の懸念があるかどうか、ライフスタイルなど)。IoC の中心的な付加価値の 1 つは、オブジェクトの作成とインスタンス管理の責任を一元化することです。それを適切に行い、懸念事項を分離するには、呼び出しシナリオでうまく機能する信頼できるアーキテクチャが必要であり、IMO は、すべてのフレーバーのインスタンスを Release() するための鉄壁の答えを持つことを意味します。私のアドバイスは、Release を呼び出せるようにする設計を常に実装することです。特にルート (つまり、コントローラー) で。

IDependencyResolver に対する最後の議論は、このレベルで統合する場合、多数の MVC システム コンポーネントを登録する必要があるということです。これは、私のアプリとその下にあるフレームワークとの間のダンスがあまりにも親密すぎて、私の好みではありません。IControllerFactory は、より対象を絞った統合ポイントを提供します。MVC システム コンポーネントを登録する必要はなく、Release() フックを取得します。したがって、MVC システム コンポーネントをオーバーライドしたい場合を除き、IControllerFactory に IDepedencyResolver を実装する理由はほとんどありません。実際には反対の議論が見られます。私は個人的に、両方のアプローチを示すこのスレッドでこれに気付きました。

お役に立てれば

于 2013-08-18T22:33:24.720 に答える