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

我刚读完John Evdemon在MSDN上发表的一篇文章.他抨击CRUD接口并将其称为反模式.

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

或者我在这里缺少什么？

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

编辑:

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

例:

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

最近获得普及的RESTfull网络服务证明了John Evdemon先生的职位错误.

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

 _
Public Function MoveNext() As Boolean
End Function

 _
Public Function Current() As Object
End Function