java - 使用 Controller、Service 和 Repository 注释的最佳实践是什么？

Question

我对 Spring-MVC 中 @Controller、@Service 和 @Repository 的用法感到很困惑。

我有几个问题，如果能得到解答，我将不胜感激。

• 我知道 Controller 用于接收来自 View 的请求并向 View 发出请求以向用户显示结果。我的问题是，我可以在带有 Controller 注释的类中进行什么程度的处理？我是否应该在服务注释类中进行所有处理，并让 Controller 只接收请求和返回响应？我想知道最佳做法是什么？

  假设我需要调用服务注释类的不同方法来处理结果，我应该从 Controller 中调用它们还是将它们传递给服务注释类？ (这只是一个例子)

• 如果我不想处理结果而只想向数据库发送请求并接收结果，我是否仍需要在 Controller 和存储库之间有一个服务注释类？

  假设我收到一个产品 ID 并想检索并显示产品的详细信息。(这只是一个示例)

Answer 1

我认为这几乎不是任何“最佳方法”，而是适合您需要的方法。这是我在过去的项目中使用的方法，它基于领域驱动设计。

1. 表示层: Controller (@Controller)

   仅负责呈现业务功能(在应用服务层提供)。因此主要委托(delegate)给 App Service，执行数据处理和与表示相关的逻辑。

2. 应用服务层:应用服务(@Service)

   从高层次上讲，它代表业务用例。因此，事务边界是在方法上设置的(因为每个方法都是一个用例，因此是一个工作单元)。因为我反对使用贫血模型，真正的业务逻辑应该在领域模型层。该层主要利用领域层来组成有意义的用例。主要是数据转换(取决于您的设计)，以及对域层工件的委托(delegate)。

3. 领域层:模型、领域服务 (@Service)、存储库 (@Repository) 等

   业务逻辑在领域模型或领域服务中。存储库是检索域模型的工件。

4. 基础设施层

   一些域工件的依赖于基础架构的实现。

回到你的问题:

• 没有对错之分。如果您正在制作一个完全独立的简单应用程序，那么将 Controller 和应用程序服务层的角色分开可能没有任何好处。此外，对于那些习惯于贫血模型开发的人来说，您可能需要一个服务来放入您的业务逻辑。因此，您需要问问自己，在设计中拥有特定层的目的是什么，是吗？对你真正有意义的东西。对于我的方法，我认为对于哪一层做什么已经很清楚了。如果需要，可以作为引用。

• 类似的回答:如果你在你的Controller中做的是Presentation + Application Service的角色，没有特殊的理由再补一个Service。但是，如果您想维护一个表现中立的应用服务层，那么您应该通过您的应用服务提供那些“CRUD”操作。