SOA 中的 CRUD 操作答案

【问题标题】：CRUD Operations in SOASOA 中的 CRUD 操作
【发布时间】：2015-02-19 23:56:51
【问题描述】：

SOA 中的 CRUD 操作：

可以在此处找到此问题的上下文：Why are CRUD operations so bad in a SOA design?

我正在开发一个接口 - 例如：Order，其中我有 CreateOrder、UpdateOrder 和 GetOrder 方法。 Order 也有 OrderLines。由于我不想将 CreateOrderLine、GetOrderLine 作为单独的方法，因此我通过 CreateOrder 和 GetOrder 方法完成这些任务。对于删除和更新，应调用 Update 方法。但我正在尝试制定删除特定 OrderLine 的模式。如何计算更新和删除之间的区别？关于如何实现DeleteOrderLine，我有以下想法：

方法一：

1a：如果您想删除一个订单行： - 填充请求中的所有 OrderLines，除了您要删除的那个。

1b：如果您想更新一个订单行： - 填充请求中的所有 OrderLines，并为您要更新的值填充新值。

2 调用 UpdateOrder 3 该实现在开始任何处理之前删除所有 OrderLineItems，并始终像添加新行一样添加这些行。

方法二： - 将某种“命令”添加到每个订单行（“添加”、“删除”、“更新”），实现可以用来执行适当的操作。 - 对于更新，使用“更新”命令标记需要更新的行。只有这些得到更新。 - 对于删除，使用“删除”命令标记需要删除的行。只有这些会被删除。

有没有人有任何其他想法或机制来完成这项工作？

谢谢。

【问题讨论】：

标签： soa crud

【解决方案1】：

显然，“简单的 CRUD”需要 REST 实现。（无意挑逗或挑逗，我自己就是 SOAP 实现者）

但是假设您仍然以 SOAP 实现为目标（因为您需要 XML 模式验证，或者您的团队已经习惯了该技术等），那么我会严格遵守 Canonical Schema Pattern (Erl) 和我将使用您的“方法 1”。

以下是方法和原因：

如何：

这样，我并不是要开始一个新的 Data Architect Babel 塔并通过 10 周的过程找出“Order Canonical™”的架构（可悲的是，这种方法经常使用)。我宁愿推动快速审查用于 GetOrder 响应的当前架构，并在所有操作中使用那个“对象”。

ie ：您在“get”的response中使用的架构与Create的requests中的架构相同，更新操作。事实上，Create 和 Update 通常可以合并以创建一个 Upsert（在 SOA 操作中通常称为 Save）。与此方法唯一的区别是创建时通常缺少主键。

这种模式强制“方法1”，这是一件好事。

原因：

恕我直言，方法 2 很少会比方法 1 更快，即使它更“优化”（我们只触及需要编辑的 OrderLines，没有其他）。恰当的例子：要使用方法 2 删除/更新少量行，您有 2 个选择：执行大量单独的删除，或使用大量精确的 WHERE 子句组合单个删除。使用方法 1（和规范模式模式），您始终删除订单的所有 OrderLines，然后重新插入它们。该算法简单易维护。

如果您尊重此模式并使用数据库事务，则数据库损坏对于您的“方法 1”来说不是问题。生成的客户端更简单（它们重复使用了许多相同的对象），最终组合服务的操作中介变得非常简单。

免责声明：

如果您确实执行了大量 OrderLine 删除和更新（我假设您没有，这些通常是手动且很少调整），我的逻辑并不完全正确。如果您确实有这么多，那么我会考虑仍然使用上述相同的操作并添加专门的 SaveOrderLine 操作（但不是 GetOrderLine 或 CreateOrderLine）。

【讨论】：

【解决方案2】：

方法 2：- 向每个订单行添加某种“命令”（“添加”、“删除”、“更新”），实现可以使用它来执行适当的操作

方法2需要创建一些复杂的更新操作图，用对象的术语来描述：

var OrderUpdateDTO = new OrderUpdateDTO(
    OrderID = 23,
    CommentChange = "An example of Order property change",
    OrderLineUpdates = [
        new OrderLineCreateDTO(
            ProductID = 1025,
            Quantity = 3
        ),
        new OrderLineUpdateDTO(
            OrderLineID = 94,
            QuantityChange = 2
        ),
        new OrderLineDeleteDTO(
            OrderLineID = 95
        ),
        new OrderLineDeleteDTO(
            OrderLineID = 96
        )
    ]
)

这种复杂图的原因是 SOA 不支持方法组合 (see here) 和性能考虑（您不能一个一个地多个小的 CRUD 服务方法，您必须进行一次调用）。

一旦创建更新图，就会调用服务更新方法：

Service.Update(OrderUpdateDTO)

服务解析此更新图并调用业务逻辑层方法来应用这些更改。

有没有人有任何其他想法或机制来完成这项工作？

方法 2 比方法 1 复杂得多，因为它需要：

为服务开发人员工作，设计更新图并实现解析更新图的逻辑
为服务客户端工作，每次更改内容时构建更新图

【讨论】：