SOA 实现中的请求/响应模式

Question

在一些类似企业的项目（.NET、WCF）中，我看到所有服务合同都接受单个 Request 参数并始终返回 Response：

[DataContract]
public class CustomerRequest : RequestBase {
        [DataMember]
        public long Id { get; set; }
}

[DataContract]
public class CustomerResponse : ResponseBase {
        [DataMember]
        public CustomerInfo Customer { get; set; }
}

其中RequestBase/ResponseBase 包含常见的东西，如 ErrorCode、Context 等。服务方法和代理的主体都包装在 try/catch 中，因此检查错误的唯一方法是查看 ResponseBase.ErrorCode（即枚举） .

我想知道如何调用这种技术，以及为什么它比传递所需的方法参数和使用标准 WCF 上下文传递/故障机制更好？

Answer 1

您所说的模式是基于契约优先开发的。但是，您不必在 WCF 中使用错误块模式，您仍然可以将错误异常抛出回客户端，而不是使用错误 Xml 块。错误块已经使用了很长时间，因此很多人都习惯了它的使用。此外，其他平台开发人员（例如 java）并不熟悉 faultExceptions，尽管它是行业标准。
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

请求/响应模式在 SOA（面向服务的架构）中非常有价值，我建议使用它而不是创建接收参数并传回值或对象的方法。当您开始创建消息时，您会看到好处。如前所述，它们是从契约优先开发演变而来的，其中首先使用 XSD 创建消息并基于 XSD 生成您的类。此过程用于经典 Web 服务，以确保您的所有数据类型都能在 SOAP 中正确序列化。随着 WCF 的出现，datacontractserializer 更加智能，并且知道如何序列化以前无法正确序列化的类型（例如，ArrayLists、List 等）。

请求-响应模式的好处是：

• 您可以从基础对象继承所有请求和响应，在这些基础对象中您可以保持公共属性的一致性（例如错误块）。
• Web 服务本质上应该需要尽可能少的文档。这种模式只允许这样做。以public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request); 之类的方法为例，默认情况下，客户端将知道要传入什么以及返回什么，而且，当他们构建请求时，他们可以看到什么是必需的，什么是可选的。假设此请求具有诸如 Carriers [Flag Enum]（必需）、StartDate（必需）、EndDate（必需）、PriceRange（可选）、MinSeatsAvailable（选项）等属性......你明白了。
• 当用户收到响应时，它可以包含比通常的返回对象更多的数据。错误块，跟踪信息，随便你，发挥你的想象力。
  在 BusScheduleResponse 示例中，这可以返回多个运营商的多个公交时刻表信息数组。

希望这会有所帮助。

请注意。不要混淆并认为我在谈论生成您自己的[MessageContract]s。您的请求和响应是 DataContracts。我只是想确保我没有让你感到困惑。没有人应该在 WCF 中创建自己的 MessageContracts，除非他们有充分的理由这样做。