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

我刚读完MSDN by John Evdemon的文章。他将CRUD界面打乱并称之为反模式。为什么在SOA设计中CRUD操作如此糟糕？

虽然我同意拥有任何有状态是困难的，Current和MoveNext是不好的想法，但我不同意在创建读取更新和删除中的CRUD不好。如果我有汽车服务，并且希望让客户能够做到这些基础知识，例如创建汽车，获取汽车细节，更新汽车细节或删除汽车，那么他们如何才能做到这些事情没有CRUD操作。

或者我在这里错过了什么？

来源

2010-10-14 uriDium

我想我得阅读文章得到了答案：因为是当光标操纵（MOVENEXT）视为一个CRUD操作？ – mikemanne 2010-10-14 13:09:44

的CRUD接口应在分布式系统/ SOA方案来避免，因为他们都非常健谈。但是，并不意味着必须。当你有一些客户动作需要多次调用你的服务时，你就会知道你应该放弃CRUD方法并创建新的服务操作，这些操作会将这些调用集中到一次调用中。在设计分布式系统时，应始终将呼叫次数降至最低，因为网络呼叫非常耗时。

编辑：

你可以考虑一下CRUD接口有关的服务所公开的数据访问。有时你真的想要这样。但是在SOA和分布式系统架构中，通常会公开业务功能，这些业务功能已经包装了数据访问并提供了更复杂的操作（汇总了许多数据访问操作）。

实施例：

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

来源

2010-10-14 09:17:11

让我困惑了一下。如果我们不公开CRUD操作，我们如何让客户创建新实体或更新他们的详细信息。例如只需一个简单的Create方法即可接受汽车。如果有问题，我们会发回故障。如果你什么都得不到，那么它是成功的。在我看来，它不会变得不那么健谈。就像我说过的，我可能会在这里错过一些大事。 – uriDium 2010-10-14 09:28:43

@uriDium：我加了一些例子。 – 2010-10-14 09:35:55

哦对。感谢这个例子。因此，CRUD几乎是一种“真正的形式”，一切都分解为基本的创建读取更新或删除是一个坏主意，因为它强制提供健谈的服务。如果您可以将它们全部包装在单一服务方法中，例如PlaceOrder（invoiceHeader，List ）会更好，因为它减少了聊天并提高了商业意识。但是，显然还有一种情况，我们可能只需要创建一个对象。我明白了吗？ – uriDium 2010-10-14 09:42:30

RESTfull web services最近越来越受欢迎被证明是错误的先生约翰Evdemon的职位。

来源

2010-10-14 09:10:14

我不这么认为，他说：“开发者在开发自己的模式之前应该咨询现有的行业标准。”那么HTTP与它的CRUD操作是你使用RESTfull Web服务的标准。恕我直言是这里的故事，它是没有意义的定义你自己的CRUD操作CRUD操作的原因有足够的解决方案已经发明。 – Stephan 2011-09-07 08:54:34

我认为他有故意设计了这里最糟糕的接口，它不是一个真正的CRUD接口。

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

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

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

更新：

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

来源

2010-10-14 09:12:26 willcodejavaforfood

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

例如，让我们说我们有一个博客API。比方说，我们让用户能够在我们的外部应用程序的一个屏幕上撰写帖子，添加图片并将所有评论放在一起。在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租户来构建我们的服务，那么我们只需要使用我们的对象进行一次调用，然后它就会尝试创建帖子的服务，例如，它的工作很好，然后尝试创建评论哪些工作正常，但当我们到达图像的服务意识到，其中一个图像网址有问题是失败的。那么我们的服务返回失败？尽管现在3个其他部分已成功存储在我们的数据存储中？我们回去撤销所有成功执行的部分吗？如果数据存储已经提交了更改，而我们不能将其还原？

的事实夫妇这样，如果我们就做它“更健谈”，并提交其个人，我们现在可以重新使用在其他应用程序的服务，而无需重新编写该服务的任何部分。

综合服务的坏的部分是，你正在上的想法，服务应该永远不会失败...这是荒谬的销售。总有一种情况会出现失败，并且将所有内容整合到一项服务中，这会增加您的复杂性，并增加您的失败能力。

我这个版本的SOA的比较，我们已经在面向对象编程建立神的对象实现的缺点。 https://en.wikipedia.org/wiki/God_object

我们知道比这使我们为什么要老调重弹的更好？与God Objects一样，合并或上帝服务是一个糟糕的主意。我说要建立你的服务来做一件事，尽可能多地使用你的服务，你的服务会很好。

来源

2015-07-14 16:52:26 Cleanshooter

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

回答

相关问题