为什么 WCF 服务使用接口作为服务契约而不是抽象类？答案

【问题标题】：Why do WCF services use interfaces as a Service Contract instead of an abstract class?为什么 WCF 服务使用接口作为服务契约而不是抽象类？
【发布时间】：2012-01-23 18:47:09
【问题描述】：

这是我在一次采访中被问到的一个问题。

当你创建一个 WCF 服务时，你会得到两个文件； “IService.cs”和“Service.cs”。为什么它是实现接口的类而不是继承抽象类的类。不要回复说您不能将 [servicecontract] 属性放在抽象类上。我知道你只能将它应用于接口，但为什么呢？

【问题讨论】：

标签： wcf web-services servicecontract

【解决方案1】：

一个人可以实现多个接口。只能继承一个抽象类。

【讨论】：

我在采访中说过，但是他们说在一个wcf服务中实现两个服务契约的可能性很小。
我没有说多个服务合同（虽然我已经看到这样做了，两个合同有不同的安全要求）；我指的是任何类型的接口。
@fahed。我们有多个实现多个接口的服务，所以这并不罕见！
确实，这很适合接口隔离原则，不同的消费客户端可能希望不同的“视图”进入同一个支持 API。
可以实现多个接口 true。但我也可以继承一个抽象类并仍然实现多个接口（假设抽象类用 [servicecontract] 属性装饰）。

【解决方案2】：

如果您将服务的实现指定为您已将客户端与服务紧密耦合的服务，WCF 会将客户端与服务完全分离。

【讨论】：

【解决方案3】：

我能想到的几个原因：

明确的意图声明 - “这组 API 签名与任何可能的实现完全分离”。相比之下，抽象类（在我看来）更像是“此基类旨在与这组派生类一起使用”的声明。
更开放的修改 - 一旦你继承一个基类，就是这样。既然[ServiceContract] 没有实现，为什么要浪费你拥有的一个继承槽呢？例如，我们所有的服务类都继承自一个抽象的ServiceBase 类，该类除了实现[ServiceContract] 接口外，还提供通用的上下文状态和方法。但是，即使不是这种情况，我仍然会保留基类插槽以供将来使用。
如果合适，它允许一个服务类实现多个[ServiceContract]。
如果您使用的是严格的合同版本控制系统，该系统依赖于从另一个继承 [ServiceContract]，那么将服务类添加到同一继承树将毁掉它。

【讨论】：