CaliburnMicroとnHibernateを利用した新しいLOBMVVMプロジェクトのアーキテクチャを設計しようとしていますが、現在、DIとIOCを調査しています。
Caliburn Microをブートストラップするための多くの例では、DI\IOCメカニズムとしてMEFを使用しています。
私が苦労しているのは、MEFはかなり人気があるように見えますが、Mef [Imports]アノテーションのアイデアは、サービスロケーターの別のフレーバーのように私にはにおいがしますか？
私が見たほとんどすべての例がMEFを正しく使用していないという点で、MEFについて何かが足りないのでしょうか、それとも、サービスロケーターの問題全体を回避するために、MEFがどのように使用されているのかを完全に理解していないのでしょうか。
MEFは、それ自体がサービスロケーターではありません。これを使用してサービスロケーターを実装できます（ SilverlightバージョンのCompositionInitializerは、事実上MEFに組み込まれているサービスロケーターです）が、依存性注入を直接実行することもできます。
属性はあなたに「においがする」かもしれませんが、[ImportingConstructor]作成時にデータを挿入するために使用できるので、属性だけではこれがサービスロケーターになることはありません。
MEFを使用する方法は、実際には属性だけではないことに注意してください。代わりに、直接登録または規則ベースの登録を介して機能することもできます（CodePlexドロップおよび.NET 4.5でサポートされています）。
newプロパティがインポートされたパーツをアップして使用しようとすると、ここで説明したのと同じ問題のいくつかに遭遇する可能性があると思います。ServiceLocatorはアンチパターンです。
ただし、実際には、コンテナからパーツを取得します。[Import]追加のallowDefaultプロパティなしで使用する場合は、パーツが必要であり、インポートを行うパーツを要求すると、コンテナが爆発します。はい、実行時に爆発しますが、ミルサービスロケーターの実行とは異なり、テストフレームワークを使用してMEFコンテナーの静的分析を行うのはかなり簡単です。私はこことここでそれについて数回書いた。
いくつかの理由から、実際には問題にはなりませんでした。