MEF與任何IoC

Question

看着微軟的託管擴展性框架（MEF）和各種IoC容器（例如Unity），我無法看到何時使用一種類型的解決方案。更具體地說，MEF似乎處理大多數IoC類型模式，並且象Unity這樣的IoC容器不是必需的。

理想情況下，我想看到的IoC容器將被用來代替，或除，MEF一個良好的使用情況。

Answer 1

當煮濃後，主要的區別是，IoC容器通常是具有靜態依賴（在編譯時已知的）最有用的，並且通常MEF與動態依賴性（僅在運行時已知的）最有用的。

因此，它們都是合成引擎，但每種模式的重點都不相同。因此設計決策變化很大，因爲MEF圍繞未知部件的發現進行了優化，而不是已知部件的註冊。

想想這樣：如果你正在開發你的整個應用程序，一個IoC容器可能是最好的。如果您正在編寫可擴展性，那麼第三方開發人員將擴展您的系統，但MEF可能是最好的。

此外，在@Pavel尼科洛夫的答案的文章提供了一些大的方向（它是由MEF的項目經理格倫塊，寫的）。

Answer 2

我同意MEF可以是完全有能力的IoC框架。實際上，我正在編寫一個基於使用MEF的擴展性和IoC的應用程序。我將它的通用部分加入到了一個「框架」中，並將其作爲自己的框架開放，稱爲SoapBox Core，以防人們想要了解它是如何工作的。

特別是，看看在Host是如何工作的，如果你想看到MEF在行動。

Answer 3

我一直在使用MEF了一段時間，因爲當我們用它代替IOC產品的關鍵因素是，我們經常有一個給定的接口在特定的時間坐在我們的插件目錄中的3-5實現。實際應該使用哪一種實現實際上只能在運行時才能決定。

MEF擅長讓你做到這一點。通常情況下，IOC的目標是確保您可以在未來的某個時間換取基於ORM產品1的ORM產品2的IUserRepository作爲一個典型例子。但是，大多數IOC解決方案都假定在給定時間只有一個IUserRepository有效。

但是，如果您需要根據給定頁面請求的輸入數據選擇一個，IOC容器通常處於虧損狀態。

舉個例子，我們做我們的權限檢查，並通過MEF插件我們的驗證一個大的web應用程序我已經工作了一段時間。使用MEF，我們可以查看記錄的CreatedOn日期和挖掘實際上在記錄創建時實際有效的驗證插件，並通過該插件和當前有效的驗證程序運行記錄BOTH，並比較記錄的有效性時間。

這種功能還可以讓我們定義插件的fallthrough覆蓋。我正在使用的應用程序實際上是爲30多種實現部署的相同代碼庫。因此，我們通常會通過詢問以尋找插件：

1. 特定於當前站點和特定記錄類型的接口實現。
2. 特定於當前網站的接口實現，但適用於任何種類的記錄。
3. 適用於任何網站和任何記錄的接口。

這讓我們捆綁一系列默認插件，但只有當特定的實現沒有用客戶特定的規則覆蓋它時。

國際奧委會是一項偉大的技術，但似乎真的更多的是關於使它容易的代碼接口，而不是具體實現。然而，將這些實現交換出去更像是IOC項目轉移的一種事件。在MEF中，您可以靈活使用接口和具體實現，並使其成爲許多可用選項之間的運行時決策。

Answer 4

我爲脫離主題而道歉。我只想說，有2個缺陷，使MEF的不必要的複雜：

• 它是基於屬性，它不會做任何好幫你弄清楚爲什麼事情的工作，因爲他們做的。沒有辦法瞭解框架內部的細節，看看究竟發生了什麼。沒有辦法獲得跟蹤日誌或連接到解析機制並手動處理未解決的情況。

• 它沒有任何故障排除機制來找出某些部件被拒絕的原因。儘管指出了一個失敗的部分，但它不會告訴你爲什麼該部分失敗。

所以我很失望吧。我花費了太多時間與風車試圖引導一些班級而不是解決真正的問題。我確信，當你完全控制VS調試器中創建的內容，時間以及可以跟蹤的任何內容時，沒有比老派的依賴注入技術更好的了。我希望有人主張MEF提出了一系列很好的理由，爲什麼我會選擇純粹的DI。