Question

这有“规则”吗？我想知道的是有最佳实践，告诉如何将功能组合到一个操作。例如，SetRecord-operation：如果为某种记录指定了id，则操作会更新记录，否则操作会创建记录。在这种情况下，返回消息将告知是否进行了插入或更新，但这是不好的设计（如果是，为什么）？

另一个例子是包含记录的层次结构，有时它想要创建所有级别的层次结构，有时是2级，有时只有1级。（坏）例子是hiearchy汽车座椅扶手。有时只创建汽车或单个座位。有时会创建一个有4个座位的汽车（每个都有2个扶手）。这应该如何映射到wsdl-operations和类型。如果你有意见我想知道为什么？我必须说我在这里有点迷失。

谢谢，BR - Matti

Answer 1

尽管这样做没有问题，但它违反了良好编程模式的一些原则。

您的方法以及您的课程应该只做一件事，而不是一件事。 Single Responsibility Principle完全是这样说的：

单一责任原则（SRP）说一个班级应该有一个，也是唯一一个改变的理由。用不同的方式说这个，一个类的方法应该因为同样的原因而改变，它们应该不受不同力量的不同影响。

它也可能违反其他一些原则，例如：

Separation of concerns
Cohesion

我甚至不必说它会导致很多Code Smells像：

长方法
条件复杂性

检查this好文字。

Answer 2

我做了一些研究，我认为上面的答案是对wsdl接口设计的非常狭隘的看法。将我的问题的示例Insert和Update to Set组合起来是一种愚蠢的做法，即在数据上推断完成的操作（检查id或类似的填写请求消息）。所以在这种情况下它很糟糕，因为界面并没有真正说明会发生什么。拥有2个独立的操作要清晰得多，不会消耗更多的资源。

然而，组合操作可以是正确的做事方式。想想我的数据示例：它需要13个请求才能拥有一个有4个座位的汽车，所有座位都有两个扶手。所有过境点都应该是昂贵的。所以这个可以合并为单一操作。

阅读例如：

Is this the Crudy anti pattern?

和

http://msdn.microsoft.com/en-us/library/ms954638.aspx

你会发现上面的答案肯定是过度简化而且所有的编程原则都不能自动应用于Web服务界面设计。

上面的答案中的好例子是创建第一顺序标题，并且它们具有单独请求的订单项是不好的，因为例如它可能很慢而且不可靠。它们可以合并到

PlaceOrder(invoiceHeader, List<InvoiceLines>)

所以答案是：这取决于你的组合。太低级别的CRUD - 有点事情是不可取的，但也要结合不需要合并的东西。此外，定义清晰的界面和清晰的消息结构，直接告诉我们将要做什么是关键，而不是简单地将其简化为多个/单个。

-Matti

将多个函数组合到wsdl中的单个操作是否可以？

2 个答案: