在服务层(WCF)中使用MEF

在服务层(WCF)中使用MEF

问题描述:

到目前为止,我发现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可能会添加该值,但它对服务函数非常具体。我们需要深入服务的要求来做出这个决定。

学习正在进行中,所以大家请分享您的想法和经验。

我认为任何情况都会从关注点分离中受益,从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

我正在研究一个解决方案,我希望跨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

不久之前我不知道我该如何创建一个WCF Web服务,将让所有的依赖通过MEF有线的但我wouldnt需要写一个在我的服务类中连接线的代码。

我也希望它完全基于配置,所以我可以将我的通用解决方案带到下一个项目中,而无需更改代码。

我的另一个要求是我应该能够以简单的方式对服务进行单元测试并模拟出不同的依赖关系。

我想出了香港专业教育学院的博客上讲述这里的解决方案:Unit Testing, WCF and MEF

希望将帮助人们试图做同样的事情。