为什么CRUD操作在SOA设计中如此糟糕? [英] Why are CRUD operations so bad in a SOA design?

查看:118
本文介绍了为什么CRUD操作在SOA设计中如此糟糕?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

刚刚阅读了有关 John Evdemon的MSDN 的文章。他基于CRUD界面,并将其称为反模式。

I have just finished reading an article on MSDN by John Evdemon. He bashes the CRUD interfaces and calls it an anti-pattern.

虽然我同意拥有任何状态是困难的,而Current和MoveNext是坏主意,我不同意创建读取更新和删除中的CRUD是坏的。如果我有一个汽车服务,我想让客户能够做基本的事情,如创建一个汽车,获取汽车的细节,更新汽车的细节或删除一辆汽车,那么他们是如何做这些事情没有CRUD操作。

While I agree that having ANYTHING stateful is difficult and Current and MoveNext are bad ideas I don't agree that CRUD as in Create Read Update and Delete are bad. If I have a car service and I want to let clients be able to do the basics, as in Create a car, get a cars details, update a cars details or delete a car then how are they meant to be able to do those things without CRUD operations.

或者我在这里缺少什么?

Or what am I missing here?

推荐答案

在分布式系统/ SOA场景中应避免使用CRUD接口,因为它们非常闲聊。但不应该意味着。当您有一些客户端操作需要多次调用您的服务时,您将知道您应该放弃CRUD方法并创建新的服务操作,将这些调用集中到单个调用。在设计分布式系统时,您应该总是将呼叫次数减少到最小,因为网络呼叫非常耗时。

The CRUD interfaces should be avoided in distributed system / SOA scenario because they are very chatty. But should doesn't mean have to. When you have some client actions which require more than one call to your service then you know that you should give up CRUD approach and create new service operation which will agregate those calls into single call. When designing distributed system you should always reduce number of calls to minimum because network call is very time consuming.

编辑:

您可以在服务中公开的数据访问中考虑CRUD界面。有时你真的想要这个。但是,在SOA和分布式系统架构中,您通常会暴露已经包装数据访问的业务功能,并提供了更复杂的操作(它会聚集许多数据访问操作)。

You can think about CRUD interface as about data access exposed in a service. Sometimes you really want this. But in SOA and distributed system architecture you are usually exposing business functionality which already wraps data access and offers much more complex operations (which agregate many data access operations).

示例:

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

CRUD x Business logic interface. Suppose that you are working with Invoices. Each invoice consists of an InvoiceHeader and one or more InvoiceLine. If you use a CRUD interface for invoice you will first call CreateInvoiceHeader operation to create InvoiceHeader and then several AddInvoiceLine operations to add all InvoiceLines - that is low level CRUD approach. But if you implement business logic on the service side you will call single CreateInvoice and pass a complex object graph (header with all lines) to the service to create and add what is needed. The Create method can also do other business operations like starting some workflow etc. That is common SOA and distributed system approach.

这篇关于为什么CRUD操作在SOA设计中如此糟糕?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆