0

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

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

谢谢和BR-马蒂

4

2 回答 2

3

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

你的方法和你的类应该只做一件事，不超过一件事。单一职责原则准确地说：

单一职责原则 (SRP) 说，一个类应该有一个，而且只有一个改变的理由。换一种说法，一个类的方法应该因为同样的原因而改变，它们不应该受到以不同速率改变的不同力量的影响。

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

关注点分离
凝聚力

我什至不必说它会导致很多代码气味，例如：

长方法
条件复杂度

检查这个好文本。

于 2012-10-29T11:37:50.387 回答
0

我做了一些研究，我认为上面的答案对 wsdl 接口设计提出了相当狭隘的看法。将我的问题的示例 Insert 和 Update 结合到 Set 中，以根据数据推断完成的操作是愚蠢的（检查 id 或类似内容是否填充了请求消息）。所以在那种情况下它很糟糕，因为界面并没有真正说明会发生什么。拥有 2 个单独的操作更加清晰，并且不会消耗更多资源。

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

例如阅读：

这是 Crudy 反模式吗？

和

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

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

上面 SO-answer 中的好例子是创建 1st order 标头，它们带有单独请求的 orderitems 是不好的，因为例如它可能很慢且不可靠。它们可以组合成

PlaceOrder(invoiceHeader, List<InvoiceLines>)

所以答案是：这取决于你在结合什么。太低级的 CRUD 有点不可行，但也不应该组合不需要组合的东西。此外，使用清晰的消息结构定义清晰的界面，直接告诉将要做什么是这里的关键，而不是将其简单地定义为多个/单个。

-马蒂

于 2012-11-01T17:43:53.673 回答