[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上下文传递/故障机制更好？
您正在谈论的模式是基于合同第一发展。但是，不必在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的出现，数据采集器更加智能化，并且知道如何序列化以前不能正确序列化的类型(例如，ArrayLists，List等)。
请求响应模式的好处是：
>您可以继承基础对象的所有请求和响应，您可以在其中保持常见属性的一致性(例如错误块)。
> Web服务本质上应尽可能少的文档。这种模式允许这样。以例如公共BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest请求)为例;默认情况下，客户端会知道要传递的内容以及它们正在恢复的内容，以及在构建请求时，他们可以看到需要的内容以及可选的内容。说这个请求有像Carriers这样的属性[Flag Enum](必需)，StartDate(必需)，EndDate(必需)，PriceRange(可选)，MinSeatsAvailable(Option)等等…你得到了点。
>当用户收到响应时，它可以包含比通常的返回对象更多的数据。错误阻止，跟踪信息，无论如何，使用您的想象力。
在BusScheduleResponse示例中，这可以返回多个操作符的总线调度信息的多个数组。
希望这可以帮助。
一句话要小心。不要困惑，认为我正在谈论生成你自己的[MessageContract]。您的请求和响应是DataContracts。我只是想确保我不会混淆你。没有人应该在WCF中创建自己的MessageContracts，除非他们有很好的理由这样做。