wcf - 在服务层 (WCF) 中使用 MEF

Question

到目前为止，我发现 MEF 与表示层配合得很好，具有以下优点。

一个。 DI(依赖注入(inject))

第三方可扩展性(请注意，所有相关方都应使用 MEF 或需要包装器)

自动发现部件(扩展)

MEF 允许使用附加元数据标记扩展，这有助于丰富的查询和过滤

可与“DLR 和 c# 动态引用”或“类型嵌入”一起用于解决版本控制问题

如果我说错了请指正

我正在研究是否在 WCF 的服务层中使用 MEF。请分享您同时使用这两者的经验以及 MEF 如何帮助您？

谢谢，

尼尔斯

---

更新

这是我目前的研究结果。感谢 Matthew 的帮助。

1. 核心服务的 MEF - 变更成本并不能证明 yield 的合理性。这也是一个重大决定，可能以好的或坏的方式影响服务层，因此需要大量研究。 MEF V2(等待稳定版本)在这种情况下可能更好，但不太担心在这里使用 MEF V1。

2. 功能服务执行的 MEF - MEF 可能会增加值，但它非常特定于服务功能。我们需要深入了解服务需求才能做出该决定。

学习是一个持续的过程，所以请大家分享你的想法和经验。

Answer 1

我认为任何可以从关注点分离中受益的情况都会从 IoC 中受益。您在这里面临的问题是如何要求在您的服务中使用 MEF。是针对核心服务本身，还是服务执行的某些功能。

例如，如果您想将服务注入(inject)到您的 WCF 服务中，您可以使用类似于 MEF for WCF 的东西CodePlex 上的示例。我没有深入研究它，但本质上它通过 IInstanceProvider 包装服务位置，允许您自定义服务类型的创建方式。不确定它是否支持构造函数注入(inject)(这是我的偏好)......？

如果 WCF 服务组件不在您要使用 MEF 的位置，您仍然可以利用 MEF 创建服务使用的组件子集。最近在我工作的公司，我们一直在重建我们的报价流程，我已经建立了一个灵活的工作流计算模型，其中工作流单元是由 MEF 组成的部分，可以在需要的地方插入。这里的重要部分是管理与 WCF 服务生命周期相关的 CompositionContainer 的使用方式(例如单例行为等)。如果您决定每次都创建一个新容器，这一点非常重要(创建容器非常便宜，而创建目录可能很昂贵)。

希望对您有所帮助。