java - 使用服务模式和使用独立存储库 Spring Data REST 有什么区别？

Question

单独使用 Spring Data REST 存储库并围绕它实现“服务”模式(即 ItemService 、 ItemServiceImpl 等)有什么区别？
乍一看，功能或多或少相同，不同之处在于服务方法允许更好的定制，但它也会产生大量的样板代码(实现和 Controller )。这是an example (看 Payment 和 CreditCard 实体)使用这两种方法 - Oliver Drotbohm 的 RESTBucks。
那里的支付抽象使用使用的“服务”模式(PaymentService、PaymentImpl 然后 PaymentController 和 web 文件夹中的所有方法)，而订单直接通过 Spring Data REST 公开。

Answer 1

tl;博士
支付功能处于更高的抽象级别，因为它不遵循既定的 HTTP 资源模式(集合资源、项目资源，一般来说:描述的那些 here)，因此保证自定义服务实现。相比之下，订单聚合的生命周期确实遵循这些模式，因此除了 Spring Data REST 暴露和一些自定义之外不需要任何东西。查找有关两个实现部分如何相互关联的概念概述 here .
细节
这是一个很好的问题。示例应用程序旨在展示 API 的不同部分如何由不同的需求驱动，以及您如何使用 Spring Data REST 来处理遵循既定模式的部分，同时通过更高级别的方面来增强它需要表达业务流程。
该应用程序分为两个主要部分:以 Order 为中心的订单处理。经过不同阶段的聚合。有关这些的概念概述可以在 here 中找到。 .因此，我们用于订单的部分 API 将遵循标准模式:可过滤的收集资源以查看所有订单、添加新订单等。这就是 Spring Data REST 的亮点。
支付部分不同。它需要以某种方式融入订单处理的 URI 和功能空间。我们通过以下步骤实现:

我们在 dedicated service 中实现了所需的功能.存储库交互与必要的抽象级别不匹配，因为我们必须验证 Order 上的业务约束。和 Payment聚合。该逻辑需要存在于某个地方:在服务中。

我们通过 a Spring MVC controller 公开该功能因为我们(目前)不需要像列出所有付款这样的标准模式。请记住，该示例围绕订购流程建模，而不是会计后端。支付资源混入订单的URI空间:/orders/{id}/payment .

我们使用超媒体元素来指示何时可以由 adding a link 触发该功能有条件地指向这些资源，以便客户端可以使用这些元素的存在或不存在来决定提供哪些 UI 可供性来触发该功能。

以下是我认为这种方法的优点:

您只需手动编码从业务角度来看很重要的部分。无需为遵循完善模式的 API 部分实现大量样板代码。

客户不需要关心接缝的确切位置。使用超媒体元素，API 对客户端来说只是一回事。服务器甚至可以将支付资源移动到不同的 URI 空间或不同的服务。

资源
This deck讨论我详细描述的内容。这是一个 video recording其中。如果你对超媒体驱动的更高层次的想法感兴趣，我建议你 this slide deck ， 也