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

您所谈论的模式基于Contract First开发。但是，在WCF中使用错误块模式并不是必需的，您仍然可以将faultexceptions返回给客户端，而不是使用Error Xml块。 Error块已经使用了很长时间，因此很多人都习惯使用它。此外，其他平台开发人员（例如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（Option）等属性...您明白了这一点。
当用户收到响应时，它可以包含比通常的返回对象更多的数据。错误块，跟踪信息，无论如何，使用你的想象力在BusScheduleResponse示例中，这可以返回多个运营商的多个公交车时刻表信息阵列。

希望这会有所帮助。

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

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

1 个答案: