我发现基类的继承和概念是OOP的最强点。但是在SOA中并不鼓励这样做。那么，在SOA中克服这种限制的流行模式是什么？能否请您提供解释（在WCF中使用代码演示）这些模式的教程？
注意：这不是关于SOA中可用模式的一般问题。但它更具体地针对上述问题。
注意：我正在使用WCF进行SOA。
读：
答案 0 :(得分：4)
我发现基类的继承和概念是OOP的最强点。
不要过高估计继承的力量 - 几乎所有的GoF模式都是为了避免错误地使用继承。
但SOA并不鼓励这样做。
通常不鼓励它。为什么？因为在SOA中，您有一项提供某些操作的服务。服务本身由服务描述（合同/接口）定义。在SOAP服务的情况下，在WSDL中描述了契约。如果您需要另一个服务提供相同的操作集，而您的行为稍有不同，您将再次实现接口并将客户端定位到新服务（通过提供新的端点URL）。因此，服务合同的继承“有效”，但它与数据合同的工作方式不同。
每个服务操作通常接受一些数据并返回一些数据。这些数据再次在服务描述中描述。在SOAP服务的情况下，数据被描述为XSD。当您从客户端向服务发送数据（或反向）时，必须序列化数据，并且目标必须能够对它们进行反序列化（除非您希望直接使用SOAP信封，或者除非您希望使用xsd：any =无类型的XML作为传递数据）。如果要在数据协定中使用继承，则必须以某种方式将有关派生合同的信息包含在服务描述中。只有在将此信息包含到服务描述中之后，您才能告知服务使用者有关继承数据合同的存在（他们需要此信息才能使用派生类型）。
WCF提供了处理继承数据协定的能力。您可以使用KnownTypeAttribute，ServiceKnownTypeAttribute属性或DataContractResolver。您还可以查看此great article了解详情。
如果是非互操作且紧密耦合的系统（非SOA），您还可以使用NetDataContractSerializer，它允许您使用继承而没有任何限制，因为每个序列化消息包含有关反序列化所需的CLR类型和具有服务的客户端的信息应该共享数据合同集。
答案 1 :(得分：4)
无论您是否认为SOA是由SOAP，REST或消息传递实现的，服务都是以文档为中心的。 Services are not object-oriented
虽然多态性是OOD中强大的设计工具，但它不适用于SOA，因为SOA建模不涉及类。
答案 2 :(得分：0)
在SOA中不推荐继承的一个原因是因为您的代码是以模型为中心的。您有明确定义的入口和出口模型，您的代码应在两者之间进行转换，并执行任何业务逻辑。
继承只是意味着对象之间的关系难以建模和/或随时间变化。基本上这意味着使用POCO模型对象。
如果您想为您添加业务逻辑，请使用mixins来模仿继承。