为什么 SOA 设计中的 CRUD 操作如此糟糕？

Question

我刚刚读完 John Evdemon 撰写的 MSDN 上的一篇文章。他猛烈抨击 CRUD 接口并将其称为反模式。

虽然我同意让任何东西有状态是很困难的，并且 Current 和 MoveNext 是坏主意，但我不同意 Create Read Update 和 Delete 中的 CRUD 是坏主意。如果我有汽车服务，并且我想让客户能够执行基本操作，例如创建汽车、获取汽车详细信息、更新汽车详细信息或删除汽车，那么他们如何能够执行这些操作没有 CRUD 操作。

或者我在这里缺少什么？

Answer 1

在分布式系统/SOA 场景中应避免使用 CRUD 接口，因为它们非常繁琐。但应该并不意味着必须。当您有一些客户端操作需要多次调用您的服务时，您就知道应该放弃 CRUD 方法并创建新的服务操作，将这些调用聚合为单个调用。在设计分布式系统时，您应该始终将调用次数减少到最少，因为网络调用非常耗时。

编辑：

您可以将 CRUD 接口视为服务中公开的数据访问。有时你真的想要这个。但在 SOA 和分布式系统架构中，您通常会公开已经封装了数据访问并提供更复杂的操作（聚合许多数据访问操作）的业务功能。

示例：

CRUD x 业务逻辑接口。假设您正在使用发票。每张发票均由一个 InvoiceHeader 和一个或多个 InvoiceLine 组成。如果您对发票使用 CRUD 接口，您将首先调用 CreateInvoiceHeader 操作来创建 InvoiceHeader，然后调用几个 AddInvoiceLine 操作来添加所有 InvoiceLines - 这是低级 CRUD 方法。但是，如果您在服务端实现业务逻辑，您将调用单个 CreateInvoice 并将复杂的对象图（包含所有行的标头）传递给服务以创建和添加所需的内容。 Create 方法还可以执行其他业务操作，例如启动某些工作流等。这是常见的 SOA 和分布式系统方法。

Answer 2

最近流行的 RESTfull Web 服务 事实证明 John Evdemon 先生的帖子是错误的。

Answer 3

我认为他故意在这里设计了最糟糕的界面，而且它并不是真正的 CRUD 界面。

<WebMethod()> _
Public Function MoveNext() As Boolean
End Function

<WebMethod()> _
Public Function Current() As Object
End Function

这两个方法显然不是无状态的，但它们也不是真正的 CRUD 接口所需要的。我认为这只是一个写得非常糟糕的例子，它与 CRUD 操作并没有真正的关系。

更新：

发现一个类似的问题，有一个非常好的答案:)

Answer 4

接受的答案是不正确的。尽管 John 使用 CRUD 作为反模式示例，但使用 CRUD 对于 SOA 来说并不坏。 John 描述了 SOA 的问题：它会增加服务级别的复杂性，最终导致对多个用例的支持减少。我们构建 API 的主要原因之一是提供对多个应用程序的访问，这是构建 API 的主要投资回报率。

例如，假设我们有一个博客 API。假设我们让用户能够在外部应用程序的一个屏幕上撰写帖子、添加图像和发表评论。在 John 的 SOA 愿景中，他可能会建议我们构建 API 以使用一次调用来完成所有这些事情，这样就不会那么啰嗦和废话……所以：

{
  "post_title": "New Post",
  "post_content": "Some Stuff....",
  "comments": [{
    "comment": "This is right on!",
    "userId": 101
  }, {
    "comment": "I agree.",
    "userId": 105
  }],
  "images": [{
    "imgURL": "http://some.img.com/1"
  }, {
    "imgURL": "http://some.img.com/2"
  }]
}

现在显然存在三个不同的数据对象需要单独存储在这里：帖子、评论和图像。从数据存储的角度来看，帖子会转到 POSTS 表，评论会转到 COMMENTS 表，图像会转到 IMAGES 表。因此，如果我们按照 John 描述的那样按照 SOA 租户构建我们的服务，我们会对我们的对象进行一次调用，然后它会尝试创建帖子，例如，工作正常，然后它会尝试创建帖子注释工作正常，但当我们访问图像时，服务意识到其中一个图像 URL 有错误，因此失败。那么我们的服务返回失败？即使其他 3 个部分现在已成功存储在我们的数据存储中？我们是否要返回并撤消所有成功执行的部分？如果数据存储已经提交了更改，并且我们无法将其回滚怎么办？

再加上这样一个事实：如果我们让它变得“更健谈”并单独提交它们，我们现在可以在其他应用程序中重复使用这些服务，而无需重写服务的任何部分。

综合服务的不好之处在于，你被认为服务永远不会失败……这是荒谬的。总会有一种边缘情况，某些事情会失败，通过将所有内容整合到一项服务中，您增加了复杂性，实际上也增加了失败的能力。

我会将这个版本的 SOA 与我们在面向对象编程中构建上帝对象时已经认识到的缺点进行比较。 https://en.wikipedia.org/wiki/God_object

我们比这更清楚，所以为什么我们重述一下吗？联合或上帝服务就像上帝对象一样是个坏主意。我说构建你的服务来做一件事，并在尽可能多的用例中做好它，你的服务就会很好。