为什么WCF被设计成违反Liskov替代原则？

Question

当您想通过WCF发送您自己的类型时，您必须向您的合同的接口定义中添加大量的[ServiceKnownType(typeof(MyFirstConcreteType))]。您不能相反地使用[ServiceKnownType(typeof(IMyInterface))]，尽管这将编译，然后在运行时失败。

在定义MyExtendedFirstConcreteType : MyFirstConcreteType时，还必须添加一个额外的[ServiceKnownType(typeof(MyExtendedFirstConcreteType))]。

这显然违反了Liskov替换原则，因为您不能在可以使用基本类型的地方使用派生类型。

为什么WCF设计有这个缺陷？有很好的解决办法吗？

虽然这些问题与代码猴子无关，但是软件架构师应该了解他所选择的技术，了解它们的优缺点，并将这些知识应用到项目中。团队领导可以使用架构师的输入来确定是否有足够的团队成员对这些技术有足够的知识，或者估计培训和引入的成本，而不是停留在团队经验丰富的技术上。质量部门的人可能会因为听到运行时错误出现而感到不安，这很难通过自动化测试方法来避免--架构师可能需要一些很好的理由来接受这个错误。等。

Answer 1

我的理解是，这是一个将xml反序列化为实际具体类的问题。

WCF客户端需要实例化同一个类，或者至少是一个具有相同公共属性的类，作为从服务器发送的类。

当使用派生类代替指定为方法返回类型的类或接口时，就会出现问题。

使用KnownType和ServiceKnownType属性将使KnowTypes包含在WSDL中，并使返回的对象能够反序列化为正确的类型。

为什么不在发送新类时发送类信息？

WCF的关键之一是能够发布使用该服务所需的所有信息。这允许客户端能够使用自己版本的类从WSDL中自我生成。被认为是架构的一个重要方面，尽管经常避免使用“使用本地已知的类”选项。

但这需要预先了解所有可能的类。如果您动态地发送一个未包含在WDSL中的新类，客户端将被迫将基类表示为动态类或其他类，并且不知道在运行时可能包含哪些属性。

为什么不分析代码库来确定所有可能的子类型，而不是使用属性？

撇开在运行时加载类型所造成的复杂性相比，这应该是可能的。然而，WCF与当时的其他MS技术一样，广泛地使用了属性。到底是必须手工添加属性，还是通过预编译步骤自动添加属性，这真的对LSP有影响吗？