有什么样的战略在OData服务层来完成交易? [英] What strategies exist to accomplish transactions over an OData service layer?

查看:135
本文介绍了有什么样的战略在OData服务层来完成交易?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请看下面的例子:

OData服务层暴露Order和OrderLine的资源。一个消费者获取订单及相关OrderLines。消费者编辑订单,编辑订单行1,删除订单行1和1创建订单行。如何能在消费者保存所有这些变化,确保变化是全有或全无的?

据我了解的OData,这将发送几个服务电话:


  

PUT / API /订单/ 9999

  PUT / API /订单行/ 1001

  DELETE / API /订单行/ 1002

  POST / API /订单行/ 1002


每个呼叫将是无状态的,独立的,该服务器将不能够确定何时开始和结束事务。<​​/ P>



我已经考虑了各种解决方案,但我不知道其中的任何工作:

解决方法1)有订单资源包含OrderLine的信息。有了这个解决方案的单一服务调用将与进行PUT / API /顺序/ 9999,这将包含所有的OrderLine的变化。这种策略似乎好,因为它抽象从服务器上的交易明细消费者。不过,我不能找到一种方法,既微风和WCF数据服务客户端将时包括订单行收集到Order实体。此外,我不知道如何删除一个订单行会在订单沟通。有什么在的OData规范做到这一点?我发现,这是可以张贴相关的实体部分10.3.2.2产品的规格。我还没有发现用于创建/更新/把实体时删除相关的实体类似的事情。

解决方案2)使用的OData的$批量操作就送4服务电话为一体。我不知道如果$一批功能的意图是表现或将相关的服务呼叫到一个事务中。使用$批进行交易,这将是消费者,以确定哪些服务调用在同一批次发送的责任。那是关切的妥善分离?在服务器端,批量处理程序可能变得复杂。如果有订单之间发生的任何需要的验证和订单行批量处理程序将需要重新组合这些对象,并试图在数据库事务之前验证它们。

解决方案3)开始暴露和结束交易服务呼叫。再次,这将是暴露实现细节给消费者。我觉得影响是相似的解决方案2 pretty。

该解决方案必须基于.NET 4.0的工作和服务电话必须从.NET和JavaScript的客户合作。可扩展性是不是一个问题。我使用的Web API的OData,这绝不会支持$一批功能在.NET 4.0中,但切换到WCF数据服务是一种可能性。我选择的OData为它的检索功能,但如果CUD操作的交易没有OData的工作得更好,我开放的建议。一种可能性是继续使用的OData我的应用程序的高级搜索界面,但为CUD使用常规REST服务。


解决方案

一个批次会为你工作的4 4种操作一起发送,如果您使用WCF数据服务。该EF内置实施WCF数据服务将在EF操作环境的变化调用的SaveChanges,这将是全有或全无,如果调用SaveChanges调用失败,模拟交易的行为之前,在一起。

Consider the following example:

An OData service layer exposes Order and OrderLine resources. A consumer retrieves an Order and its related OrderLines. The consumer edits the Order, edits 1 OrderLine, deletes 1 OrderLine and creates 1 OrderLine. How can the consumer save all of these changes ensuring that the changes are all or nothing?

From what I understand of OData, this will be sent as several service calls:

PUT /api/Order/9999
PUT /api/OrderLine/1001
DELETE /api/OrderLine/1002
POST /api/OrderLine/1002

Each call would be stateless and independent and the server would not be able to determine when to begin and end a transaction.


I've considered various solutions but I'm not sure any of them work:

Solution 1) Have the Order resource contain the OrderLine information. With this solution a single service call would be made with "PUT /api/Order/9999" which would contain all of the OrderLine changes. This strategy seems good because it abstracts the consumer from the transaction details on the server. However, I can't find a way to include the OrderLine collection into the Order entity when PUTting with both Breeze and WCF Data Services Client. Also, I'm not sure how deleting an OrderLine would be communicated in the Order. Is there anything in the OData specification to accomplish this? I found that it's possible to POST related entities in section 10.3.2.2 of the spec. I have not found anything similar for creating/updating/deleting related entities when PUTting an entity.

Solution 2) Using OData's $batch operation would send the 4 service calls as one. I'm not sure if the intention of the $batch feature was for performance or for grouping related service calls into a transaction. Using $batch for transactions, it would be the responsibility of the consumer to determine which service calls to send in the same batch. Is that a proper separation of concerns? On the server side, the batch handler might get complicated. If there was any validation that needed to occur between the Order and OrderLine the batch handler would need to recompose these objects and validate them before attempting the database transactions.

Solution 3) Expose Begin and End transaction service calls. Again, this would be exposing implementation details to the consumer. I think the implications are pretty similar to Solution 2.

The solution must work on .NET 4.0 and the service calls must work from both .NET and javascript clients. Scalability is not a concern. I am using "Web API OData" which will never support the $batch feature in .NET 4.0 but changing over to "WCF Data Services" is a possibility. I chose OData for it's retrieve features but if transactions for CUD operations work better without OData I'm open to suggestions. One possibility is to continue using OData for my application's advanced search screens but to use regular REST services for CUD.

解决方案

A batch will work for you as the 4 four operations are send together if you are using WCF Data Services. The EF built-in implementation for WCF Data Services will make the changes in the EF operation context together before invoking the SaveChanges, which will be all or nothing if the SaveChanges call fails, emulating the behavior of a transaction.

这篇关于有什么样的战略在OData服务层来完成交易?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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