Question

我刚读完一篇关于MSDN by John Evdemon的文章。他抨击CRUD接口并将其称为反模式。

虽然我同意有任何状态是困难的，而Current和MoveNext是不好的想法我不同意CRUD在创建读取更新和删除中是不好的。如果我有汽车服务而且我想让客户能够做基本操作，例如创建汽车，获取汽车详细信息，更新汽车详细信息或删除汽车，那么他们如何能够做这些事情没有CRUD操作。

或者我在这里缺少什么？

Answer 1

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

修改

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

示例：

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

Answer 2

最近越来越受欢迎的

RESTfull web services证明了John Evdemon先生的职位错误。

Answer 3

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

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

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

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

<强>更新

找到一个非常好answer的类似问题：）

Answer 4

接受的答案不正确。尽管John使用CRUD作为使用CRUD的反模式示例，但对SOA来说并不坏。以下是John描述的SOA问题：它鼓励服务级别的复杂性增加，最终导致对多个用例的支持减少。我们构建API的主要原因之一是提供对多个应用程序的访问，这是主要ROI在构建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表。因此，如果我们按照SOA的租户建立我们的服务，就像John描述它们一样，我们用我们的对象进行一次调用，然后尝试创建帖子的服务，例如，目的，工作得很好，然后尝试创建工作正常的评论但是当我们到达图像时，服务意识到其中一个图像URL有故障就失败了。那么我们的服务会失败吗？即使其他3个部分现已成功存储在我们的数据存储中？我们回去并撤消所有成功执行的部分吗？如果数据存储已经提交了更改，我们无法将其回滚？

将这一事实与如果我们做到了这样的事实相比，更加健谈＆＃34;并且我们可以单独提交它们，现在我们可以在其他应用程序中重用这些服务，而无需重新编写服务的任何部分。

整合服务的不好之处在于，您的销售理念是服务永远不会失败......这太荒谬了。总会有一个边缘情况会出现问题，并且通过将所有内容整合到一个服务中，您增加了复杂性并实际上增加了失败的能力。

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

我们知道的比这更好，为什么我们要重复它呢？合并或上帝服务是一个坏主意，就像上帝对象。我说建立你的服务做一件事，尽可能多的用例，你的服务将是好的。

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

4 个答案: