2

私は大きなジレンマに陥っています..私はASP.NET MVC 2で高度にモジュール化されたWebアプリに取り組んでいます(実際、コアは超軽量になり、すべてモジュール/プラグインで動作します)。MEF はモジュールの検出に非常に役立つことがわかりましたが、IoC コンテナーとして使用したくありません。「真の」IoC コンテナーの高度な機能が必要になる可能性は十分にあるので、Unity を使用したいと考えています。

そしてここに問題があります:モジュールがコンテナを(プログラム的に)構成できるようにする方法=すべてのモジュールでUnityに強く依存することなく、アプリケーションの開始時に独自のタイプ(mvcコントローラー、サービスのカスタム実装...)を登録しますか? 私はCommon Service Locatorプロジェクトについて知っていますが、それはかなり良いようですが、このインターフェース共同コンテナは型の解決のみを許可し、それらを登録することはできません(afaik)。

あなたが私の言いたいことを理解してくれることを本当に願っています.

4

1 に答える 1

2

MEFをDIコンテナとして使いたくないということには確かに共感できますが、それでもアドインに適用できないかどうかを検討する必要があると思います。

MEFを使用するには、すでにアドインが必要です。そのため、すべてのアドインはMEFに強く依存します。MEFで使用されるハードコードされた属性ベースのアプローチは個人的には好きではありませんが、各アドインがDIコンテナに登録する方法を尋ねているようです。それも私にはハードコーディングのように聞こえるので、MEFを最後まで使用した方がよいでしょう。

MEF属性の適用は、コンポーネントの登録です。

MEFを本当に使用したくない場合は、他にいくつかのオプションしかありません（特に魅力的なオプションはありません）。

  • すべてのアドインがUnityに強く依存することも要求します。私はあなたがこれをしたくない理由を完全に理解していますが、完全を期すためにこのオプションを含めています
  • Common Service Locatorにも強く依存するように、すべてのアドインを要求します。私の見解では、これは問題をわずかにシフトするだけです。
  • すべてのアドインが実装する必要のある独自のアドイン登録インターフェイスを定義します。次に、Unityを使用する独自の実装を作成して、すべてのアドインがこのインターフェイスに対して登録されるようにすることができますが、多かれ少なかれMEFの機能を複製するだけです。
  • すべてのアドインをDIに適した、ただしコンテナーに依存しないスタイルで記述します。これにより、DIコンテナーの構成に問題が残り、そのためにXML構成に頼る必要があります。これは非常に脆弱なアプローチであり、すぐにメンテナンスの地獄につながる可能性があるため、完全を期すためにこのオプションを含めています。

アドインにMEFを使用しても、コアアプリケーションでUnityを使用できなくなるわけではありませんが、非常に軽量であるため、あまり意味がない場合があります。

于 2010-03-25T09:28:18.963 に答える