2011-06-07 100 views
3

到目前爲止,我發現MEF在表現層方面表現良好,具有以下優點。在服務層(WCF)中使用MEF

a。 DI(依賴注入)

b。第三方可擴展性(注意所有相關方應使用MEF或需要包裝)

c。部件的自動發現(擴展)

d。 MEF允許使用附加的元數據標記擴展,這有助於豐富的查詢和過濾

e。可用於解決版本問題以及「DLR和c#動態參考」或「類型嵌入」

請糾正我,如果我錯了。

我正在研究是否在WCF服務層使用MEF。請分享您的經驗,以及MEF如何幫助您?

感謝,

尼爾斯


更新

這裏是我的研究成果至今。感謝馬修的幫助。

  1. MEF爲核心服務 - 變更的成本沒有正當理由的好處。這也是一個很大的決定,可能會影響服務層的好壞,所以需要大量的研究。在這種情況下,MEF V2(等待穩定版本)可能會更好,但在這裏使用MEF V1時有點擔心。

  2. 函數服務的MEF執行--MEF可能會添加該值,但它對服務函數非常具體。我們需要深入服務的要求來做出這個決定。

學習正在進行中,所以大家請分享您的想法和經驗。

回答

2

我認爲任何情況都會從關注點分離中受益,從IoC中受益。您在這裏面臨的問題是您如何要求MEF在您的服務中使用。它是核心服務本身,還是服務執行的某些功能。例如,如果要將服務注入到WCF服務中,可以使用與CodePlex上的MEF for WCF示例類似的內容。我沒有看太多,但基本上它通過IInstanceProvider包裝服務位置,允許您自定義您的服務類型的創建方式。不知道它是否支持構造函數注入(這將是我的首選),但...?

如果WCF服務組件不在您想要使用MEF的位置,您仍然可以利用MEF來創建服務使用的組件子集。最近我爲公司工作的公司,我們一直在重建我們的報價流程,並且我構建了一個靈活的工作流計算模型,工作流單位是由MEF組成的部分,可以根據需要插入。這裏的重要部分是管理您的CompositionContainer與您的WCF服務的生命週期(例如單身人士行爲等)的關係。如果您決定每次創建一個新容器(容器創建相當便宜,而目錄創建可能很昂貴),這一點非常重要。

希望有所幫助。

+0

非常感謝Matthew的回覆。我喜歡你說的話。在此處列出它們以滿足每個人的利益 1. \t查看Core服務中MEF的使用情況或服務執行的某些功能。 2. \t容器創建相當便宜,而目錄創建可能很昂貴 – Nilesh 2011-06-09 05:05:52

1

我正在研究一個解決方案,我希望跨WCF調用使用的MEF部分在應用程序級別存儲在單例中。這全部在IIS中託管。這些服務被裝飾成與asp.net兼容。

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] 

在Global.asax中,我導入了零件。

[ImportMany(typeof(IOption))] 
public IEnumerable<IOption> AvailableOptions{ get; set; } 

初始化目錄和容器後,我將導入的對象複製到我的單例類。

container.ComposeParts(this); 
foreach (var option in AvailableOptions) 
    OptionRegistry.AddOption(option); 

編輯:

我的註冊表類:

public static class OptionRegistry 
{ 
    private static List<IOption> _availableOptions= new List<IOption>(); 

    public static void AddOption(IOption option) 
    { 
     if(!_availableOptions.Contains(option)) 
      _availableOptions.Add(option); 
    } 

    public static List<IOption> GetOptions() 
    { 
     return _availableOptions; 
    } 
} 

這工作,但我想使它線程安全的所以一旦它這樣做我會發布該版本。

線程安全註冊地:

public sealed class OptionRegistry 
{ 

    private List<IOptionDescription> _availableOptions; 
    static readonly OptionRegistry _instance = new OptionRegistry(); 

    public static OptionRegistry Instance 
    { 
     get { return _instance; } 
    } 


    private OptionRegistry() 
    { 
     _availableOptions = new List<IOptionDescription>(); 
    } 


    public void AddOption(IOptionDescription option) 
    { 
     lock(_availableOptions) 
     { 
      if(!_availableOptions.Contains(option)) 
       _availableOptions.Add(option); 
     } 
    } 

    public List<IOptionDescription> GetOptions() 
    { 
     return _availableOptions; 
    } 

} 
+0

請在完成後發佈線程安全解決方案! – Nilesh 2011-08-19 10:31:39

+0

非常感謝JRockers! – Nilesh 2011-08-23 09:16:22

+1

那個線程是如何安全的?我發現至少有兩種競爭條件:a)OptionRegistry的實例化不保證只發生一次。在這種情況下,它是沒有結果的(除了一些GC活動)和b)AddOption不保證同時添加多個線程的選項只添加一次。 – 2011-11-19 23:36:30

0

不久之前我不知道我該如何創建一個WCF Web服務,將讓所有的依賴通過MEF有線的但我wouldnt需要寫一個在我的服務類中連接線的代碼。

我也希望它完全基於配置,所以我可以將我的通用解決方案帶到下一個項目中,而無需更改代碼。

我的另一個要求是我應該能夠以簡單的方式對服務進行單元測試並模擬出不同的依賴關係。

我想出了香港專業教育學院的博客上講述這裏的解決方案:Unit Testing, WCF and MEF

希望將幫助人們試圖做同樣的事情。