这有“规则”吗？我想知道是否有最佳实践告诉如何将功能组合到操作中。例如 SetRecord-operation：如果为某种记录指定了 id，则操作会更新记录，否则操作会创建记录。在这种情况下，返回消息会告诉您是否进行了插入或更新，但这是否是糟糕的设计（如果是，为什么）？
另一个例子是记录的包含层次结构，有时它想要创建所有层次结构，有时是 2 级，有时只有 1 级。（不好）示例是层次结构的汽车座椅扶手。有时只创建一辆车或一个座位。有时会创建具有 4 个座位（每个座位有 2 个扶手）的汽车。这应该如何映射到 wsdl 操作和类型。如果你有意见我想知道为什么？我必须说我在这里有点迷路了。
谢谢和BR - 马蒂
【问题讨论】：
标签： web-services design-patterns wsdl
虽然这样做没有问题，但它违反了良好编程模式的一些原则。
你的方法和你的类应该只做一件事，不能超过一件事。 Single Responsibility Principle 就是这么说的：
单一职责原则 (SRP) 说一个类应该 有一个，也只有一个，改变的理由。换一种说法， 一个类的方法应该因为同样的原因而改变，它们应该 不受以不同速率变化的不同力量的影响。
它也可能违反其他一些原则，例如：
Separation of concerns
Cohesion
我什至不必说它可以导致很多Code Smells喜欢：
长方法
条件复杂度
检查this好的文字。
【讨论】：
我做了一些研究，我认为上面的答案是对 wsdl 接口设计的狭隘看法。将我的问题示例 Insert and Update to Set 结合起来是愚蠢的，即根据数据推断完成的操作（检查 id 或类似内容是否填充了请求消息）。所以在那种情况下它很糟糕，因为界面并没有真正说明会发生什么。拥有 2 个独立的操作更加清晰，并且不会消耗更多资源。
但是，组合操作可能是一种正确的做事方式。想想我的分层数据示例：需要 13 个请求才能拥有一辆有 4 个座位且所有座位都有扶手的汽车。所有过境点都应该是昂贵的。所以这个可以组合成一个单一的操作。
例如阅读：
Is this the Crudy anti pattern?
和
http://msdn.microsoft.com/en-us/library/ms954638.aspx
你会发现你上面的答案肯定是过于简单化了，所有的编程原则都不能自动应用到 Web 服务界面设计中。
上面 SO-answer 中的好例子是创建 1st order 标头，它们带有单独请求的 orderitems 是不好的，因为例如它可能很慢且不可靠。它们可以合并为
PlaceOrder(invoiceHeader, List<InvoiceLines>)
所以答案是：这取决于你要结合什么。太低级的 CRUD 有点不可行，但也不应该组合不需要组合的东西。此外，使用清晰的消息结构定义清晰的界面，直接告诉将要做什么是这里的关键，而不是将其简单地定义为多个/单个。
-马蒂
【讨论】：