1

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

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

配置条目

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

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

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

4

1 回答 1

2

正如您所展示的 - 您无需为服务合同定义接口即可使其正常工作。然而，这样做是有争议的，你的班级违反了单一责任原则（当然这正式是一个面向对象的原则——但在我看来，它是那些似乎在任何地方都是一个好主意的普遍原则之一）。

服务合同充当服务发布者和使用它的客户之间的“合同”（呃！）。因此，一旦您有客户使用它，您需要非常小心您所做的任何更改 - 特别是如果客户可能是您无法控制的第三方。根据“单一职责原则”，定义一个代表合约的接口允许您让该接口负责公共 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 和它的实现会导致代码更清晰，并且开发人员犯错误的风险更小。

于 2014-04-10T09:00:54.450 回答