WCF中使用接口作为服务契约的优势

Question

我正在寻找正确的写为什么我们需要在 WCF 中使用接口作为服务合同。我得到了这个 url Why does .net WCF Service require the Interface 并且从这里我知道我们可以在类而不是接口上编写服务合同属性。

[ServiceContract]
public class TheService
{
   // more stuff here
}

配置条目

<services>
    <service name="YourServiceName">
        <endpoint address="" behaviorConfiguration="httpBehavior" binding="webHttpBinding" contract="TheService"/>
    </service>
</services>

但非常失望的是没有得到所有正当理由，例如人们经常使用接口作为服务合同的原因？

所以请告诉我当我们使用接口作为服务合同时我们获得的所有优势。所以寻找使用接口作为服务合同的所有有效点。所以也给示例场景加分，因为为了更好地理解。谢谢

Answer 1

正如您所展示的 - 您不需要为服务合同定义接口以使其正常工作。但是，这样做有争议的是，您的班级违反了Single Responsibility 的原则（当然这是正式的 OO 原则 - 但在我看来，它是普遍原则之一，似乎在任何地方都是一个好主意）。

服务合同充当服务发布者和使用它的客户之间的“合同”（呵呵！）。因此，一旦您有客户使用它，您需要非常小心您所做的任何更改 - 特别是如果客户可能是您无法控制的第三方。根据“单一职责原则”，定义一个代表合约的接口允许您让该接口负责公共 API，将其与实现分离。

[ServiceContract]
public interface ILoggingService
{
    [OperationContract]
    void LogMessage(string message);    
}

此实现依赖于所有客户端都连接到同一个实例这一事实：

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class SingletonLoggingService : ILoggingService
{
    void LogMessage(string message)
    {

    }

}

此实现为您每次调用它提供一个新的服务实例：

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class SingletonLoggingService : ILoggingService
{
    void LogMessage(string message)
    {

    }

}

接口的优点是我可以随心所欲地处理实现（包括它的实例化模式、并发性、它在客户端会话下的行为、命名空间、类的名称等），而不是不得不担心我可能会破坏任何客户。

同意 - 即使您将服务合同定义为类，也有一些方法可以保持向后兼容性 - 但它更容易出错并且您更有可能忘记某些东西。将公共 API 与其实现分开可以使代码更简洁，并降低开发人员犯错的风险。