Question

我对Spring-MVC中@Controller，@Service和@Repository的使用感到困惑。

我有几个问题，很高兴让他们回答。

我知道控制器用于接收来自视图的请求，并为视图发出请求以向用户显示结果。我的问题是，我可以在具有控制器注释的类中进行哪些扩展处理？我是否应该在服务注释类中执行所有处理并保留控制器以接收请求并仅返回响应？我想知道什么是最佳做法？

假设我需要调用不同的服务注释类方法来处理结果，如果我从控制器调用它们或将它们传递给服务注释类？（这只是一个例子）
如果我不想处理结果并且只是愿意向数据库发送请求并接收结果，那么我是否还需要在控制器和存储库之间安装服务注释类？

假设我收到了产品ID，并希望检索并显示该产品的详细信息。（这只是一个示例）

Answer 1

嗯取决于要求，我认为最好保持控制器清洁，它们用于演示，所以你应该只保留与表示层相关的任何内容，但是，如果你需要将输入传递给服务类和从那里调用其他服务方法，我会说不要在服务类中创建一个新方法只是直接调用服务方法。

让我们说这些方法都在服务类中，我认为将输入发送到服务类是没有意义的，并且在那里有以下代码。我建议将此代码保存在控制器中，并按如下方式调用方法：

if(input is valid){
      result1 = serviceClass.dothisstuff(input);
      result2 = serviceClass.thenthisstuff(result1);
}else{
      result1 = serviceClass.dothosestuff(input);
      result2 = serviceClass.thenthosestuff(result1);
}

我想说为了将来的要求，一直使用所有三层。

Answer 2

我认为这不是任何“最佳方法”，而是适合您需要的方法。这是我在过去的项目中使用的方法，这种方法基于Domain Driven设计。

表示层：控制器（@Controller）

仅负责呈现业务功能（在应用服务层中提供）。因此，主要是授权给App Service，进行数据按摩和与演示相关的逻辑。
应用服务层：应用服务（@Service）

高级别讲，它代表业务用例。因此，在方法上设置事务边界（因为每个方法都是一个用例，因此是一个工作单元）。由于我反对使用贫血模型，真正的业务逻辑应该在域模型层中。该层主要利用域层来组成有意义的用例。主要是数据转换（取决于您的设计），以及域层工件的委托。
域层：模型，域服务（@Service），存储库（@Repository）等

业务逻辑位于域模型或域服务中。存储库是检索域模型的工件。
基础设施层

某些域工件的基础结构相关实现。

回到你的问题：

没有对错。如果您正在创建一个完全独立的简单应用程序，那么拆分Controller和Application Service层的角色可能没有任何好处。此外，对于那些习惯于贫血模型开发的人来说，您可能只需要一个服务来放置您的业务逻辑。因此，您需要问问自己，您在设计中拥有某个层的目的是什么，是它对你来说真正有意义的事情。对于我的方法，我认为对于哪一层做什么已经很清楚了。如果需要，您可以将其作为参考。
类似的答案：如果您在Controller中扮演Presentation + Application Service的角色，则没有特殊原因可以组成另一个服务。但是，如果您想维护一个与表现无关的应用服务层，那么您应该通过您的应用服务提供这些“CRUD”操作。

Answer 3

将评论转换为答案。

我建议您将业务逻辑保留在服务层中，并仅查看控制器中的特定代码。对于你的例子，它主要是意见基础，它取决于要求，如果它是一个完整的功能，然后我会把它保留在服务层，如果它只是从存储库收集一些数据，那么我将只从控制器进行不同的服务方法调用
现在你可能没有任何业务逻辑可以放入服务层，但你永远不知道将来会发生什么。因此，最好通过服务类委派您的电话。

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

3 个答案: