将wcf服务合同与接口定义分开是否有任何价值？

Question

我有一个接口ICustomerService：

public interface ICustomerService
{

  CustomerList FindAll();
}

以及实现该接口的具体类。 现在，我需要使用wcf / rest在Web上公开该方法，并且不得不将接口定义更改为：

[ServiceContract]
public interface ICustomerService
{
  [OperationContract]
  [WebInvoke(
   Method = "GET",
   UriTemplate = "Customers")]
  CustomerList FindAll();
}

我的问题是，如果有客户端想要使用通过dll引用而不是使用其余api的实现，则将这些属性附加到您的接口是否有不利影响？ 我知道使用REST的缺点，例如如果在uri中必须将参数设置为类型字符串。

Answer 1

该属性应该没有缺点，除非代码可读性强（如果您的客户端必须查看您的界面源）。

感兴趣的任何人（例如WCF框架）都可以读取该属性，或者将其忽略。 实际上，它们在任何实现类中都不可见（请参阅此问题 ）。

但是，在体系结构级别，请考虑使用2个接口，一个用于dll引用客户端，一个用于REST客户端。 一开始它们可能很相似，它们甚至可能共享相同的基本接口和实现，但是如果业务案例需要，您可以使它们彼此转移。
同样，这使您可以在WCF Web应用程序项目中保留WCF属性填充的接口，并在核心类库项目中保留干净的接口和实现。