为web服务方法定义参数的这两种方法的优缺点是什么?

Question

我有一个需要扩展的现有web服务，但它还没有投入生产。所以，我可以随意修改合同，只要我觉得合适。但是我不确定定义这些方法的最好方法。

我倾向于方法2，没有其他原因，只是我想不出好名字来给参数类!

与方法1相比，使用方法2有什么主要缺点吗?

方法1

[DataContract(Namespace = Constants.ServiceNamespace)]
public class MyParameters
{
    [DataMember(Order = 1, IsRequired = true)]
    public int CompanyID { get; set; }
    [DataMember(Order = 2, IsRequired = true)]
    public string Filter { get; set; }
}
[ServiceContract(Namespace  = Constants.ServiceNamespace)]
public interface IMyService
{
    [OperationContract, FaultContract(MyServiceFault)]
    MyResult MyMethod(MyParameters params);
}

方法2

public interface IMyService
{
    [OperationContract, FaultContract(MyServiceFault)]
    MyResult MyMethod(int companyID, string filter);        
}

Answer 1

假设您正在使用WCF和WS-I基本概要文件，那么方法2相对于方法1的最大缺点是它使将来的契约演变更加困难。参数类允许在不创建新版本契约的情况下添加新字段，而直接的方法调用则不允许(因为在WS-I Basic中，不允许重载方法)。在WCF中，您可以跳过一些障碍来绕过此限制，但这都导致可读性较差，配置更繁重的解决方案。

对于命名参数类，我发现根据它所代表的底层消息来考虑方法是有帮助的——方法名是一个操作，参数是与该操作相关联的消息。如果您告诉WCF生成消息契约(当您添加服务引用时)，您将看到所有这些东西，并且它有时可以帮助理解它们是如何联系在一起的，尽管它确实使API更加冗长并且大多数时候是不必要的。