假设有一个操作合同,例如:
[OperationContract]
void Operation(string param1, string param2, int param3);
这个可以重新设计为:
[MessageContract]
public class OperationRequest
{
[MessageBodyMember]
public string Param1 { get; set; }
[MessageBodyMember]
public string Param2 { get; set; }
[MessageBodyMember]
public int Param3 { get; set; }
}
[MessageContract]
public class OperationResponse
{
}
[OperationContract]
OperationResponse Operation(OperationRequest request);
我喜欢MessageContract的一点是我可以更加明确地控制SOAP消息的格式。
同样,我可以编写几乎相同的代码,但使用DataContract:
[DataContract]
public class OperationRequest
{
[DataMember]
public string Param1 { get; set; }
[DataMember]
public string Param2 { get; set; }
[DataMember]
public int Param3 { get; set; }
}
[DataContract]
public class OperationResponse
{
}
[OperationContract]
OperationResponse Operation(OperationRequest request);
我喜欢DataContract的一个特点是我可以定义IsRequired、Order和Name。今天,我预计唯一的使用者将是WCF客户端。然而,我想要先设计合同并尽可能地遵循SOA实践。不想让WCF指定我的SOAP、WSDL和XSD,我想让XML定义WCF层,但使用WCF生成它,以免向WCF添加任何自定义消息处理。我想遵循最常见的SOA XML约定,也就是所有标签都以小写字母开头 - 我是对的吗?同时,我想尽可能具有版本容忍性。
是否明智总是像这样创建请求和响应消息?这三种格式中哪种促进了最佳的SOA实践?我是否应该再进一步定义DataContract和MessageContract,其中MessageContract仅包含DataContract?或者,如果我真正暴露了新类型(即不要创建消息类型作为容器),我应该只使用DataContract?
这是一组复杂的问题,但我正在努力找到答案,我不确定将问题分开是否提供了足够的上下文来获得我要寻找的答案。