Question

我的任务是实现一个可用于许多不同事物的Web服务方法（读取：不存在任何要求），任何客户端都不必更改界面这里的方法应该是什么样的< / p>

[DataContract]
    public class Status
    {
        [DataMember(Order = 0)]
        public long Code
        {
            get;
            set;
        }

        [DataMember(Order = 1)]
        public string Message
        {
            get;
            set;
        }
    }

[DataContract]
    public class Data
    {
        [DataMember(Order = 0)]
        public string Name
        {
            get;
            set;
        }

        [DataMember(Order = 1)]
        public string Value
        {
            get;
            set;
        }
    }

public Status InitiateTransaction(long txnTypeId, Data [] txnData);

这个想法是客户端会根据他们想要启动的“事务”类型在数据数组中传递不同的东西。除了创建一系列执行特定事物的不同专用方法之外，这会带来什么好处呢？

Answer 1

如果建议您实施此操作的人受到羞辱，请告诉他们这种模式是一种确定的懒惰迹象。他们无法弄清楚行为的要求是什么，因此他们指定了一种方法;他们不能费心去弄清楚数据的要求，所以他们决定名字/价值对。

只有一种情况我发现这种事情是有用的。我已经看到了定义一个接受一段XML并返回一段XML的Web服务的一些价值，希望至少受到XML Schema的约束。当服务旨在与某些其他服务或以XML文档操作的其他代码段进行交互时，这是有用的。一个例子是EDI场景，当文档格式已经由行业标准或协议定义时，Web服务实际上只是服务的代理，可以完成实际工作。

看起来你的例子没有那个借口。

Answer 2

嗯，好处是 - 它有点“通用” - 取决于传入的内容。

但这也是它最大的弱点，同时也是。由于它是如此通用和通用，你实际上无法真正执行大量约束和/或有效性检查。

我已经在许多地方看到过这种方法 - 网络服务，数据库模式 - 它们通常可以在两到三个单独的“事物”中正常工作，但是它们开始变得越复杂。

我强烈建议您为要做的每件事创建特定的，经过良好检查的方法。

马克

PS：还 - 使用其他方法扩展现有服务，同时不更改任何现有接口，可以非常轻松地完成，而且不需要对客户进行任何更改 - 因此，随着需求的增长，您可以随时轻松扩展服务，没有破坏向后兼容性。

Answer 3

您还拥有这种服务，因为您在托管Web服务之上。如果您要在SOAP端点上托管它，您的客户端将为您提供“代码”和“消息”，IIS或您用于托管Web服务的任何内容都将解释为HTTP消息并调用正确的HTTP处理程序。 WCF SOAP处理程序将获取消息，该消息实际上只包含另一组代码和消息，SOAP堆栈将使用该代码和消息调用正确的服务方法并将消息传递给那个...然后再次打开消息，得到它的代码和消息，然后调用正确的东西。

在任何情况下，您都需要在某些时候实现这些方法。所以我问你的主管的问题是为什么不使用已经提供的通用代码/消息系统，标准化以及为什么以及为什么他们应该浪费你的时间让你自己实现自己的呢？

同样，Marc表示在现有客户端上向接口doesn't force any changes添加更多方法。

WCF Web服务方法建议

3 个答案: