Question

在项目中添加新的WCF服务时，Visual Studio会创建以下两个模板（为简洁起见，我删除了名称空间和注释）：

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    void DoWork();
}

public class MyService : IMyService
{
    public void DoWork()
    {
    }
}

关注YAGNI，我通常会立即将其简化为

[ServiceContract]
public class MyService
{
    [OperationContract]
    void DoWork()
    {
    }
}

基于这样的假设：总是只有一个类实现该接口，并且没有明显的优势键入所有内容两次。如果由于某些奇怪和无法预料的原因，将来会有另一个实现（或者我想为两个服务使用相同的类），我总是可以在以后需要时提取接口。毕竟，我与外界的合约是WSDL，而不是我代码中的接口。

但是，在反对Visual Studio推荐的最佳做法时，我总是持怀疑态度，因此我想问社群：

是否有一些明显的优势从一开始分割接口和WCF服务的类我错过了什么？

Answer 1

我应该在WCF中分离接口和实现吗？

是

... 没有明显的优势两次输入内容。

撇开客户模拟服务实现的能力所带来的好处（Adriano在评论中提到），消费者可以使用接口类型定义构建一个完全可操作的通道来调用服务没有别的。

事实上，消费者调用服务是generally accepted this is a superior way。添加服务引用功能最多是复杂的，在您和服务之间添加了另一层，并且在服务定义更改时将导致困难。

如果您已经将接口与实现相结合，那么您的消费者无法干净地使用您的服务，并且被迫使用WSDL +代理生成的视觉工作室混乱，这绝不是一个先决条件。最终合同，实际上可以create more problems而不是解决。

此外，如果您通过纯HTTP（而不是SOAP）公开您的操作，分离的优势甚至更大。在这种情况下，您的消费者无法添加服务引用，因此完全依赖于您提供服务定义类型（或者至少某种模式，当您分离接口时，让我们面对它，将更容易维护出）。

tenets of SOA州的第3条

服务共享架构＆amp;合同，而不是阶级。

这不仅仅是比喻性的，而是规定性的;您应该将服务的内部实现与其表面上公开的内容分离。

我应该在WCF中分离接口和实现吗？

1 个答案: