在Spring MVC框架中，业务逻辑应该放在哪里？

Question

因为我对 Spring MVC 还比较陌生，所以不知道在哪里放置业务逻辑。我有一些想法，但是由于对 Spring MVC 的了解不够，不知从何处入手。同时，我也想问一下有没有人知道在哪里可以找到一个好的教程或完整的 Spring MVC Web 应用程序示例，其中包含业务逻辑？无论如何，我说的业务逻辑主要涉及数据库处理方面 :)

- Mark Vincent Osea

Answer 1

@Controller类作为MVC架构中的C。请注意，在Spring MVC中，真正的控制器是DispatcherServlet，它将使用特定的@Controller类来处理URL请求。

@Service类应该用于您的服务层。在这里，您应该放置您的业务逻辑。

@Repository类应该用于您的数据访问层。在这里，您应该放置CRUD逻辑：插入，更新，删除、选择。

@Service、@Repository和实体类将成为MVC中的M。JSP和其他视图技术（例如JSP、Thymeleaf等）将符合MVC模式中的V。

@Controller类只能通过接口访问@Service类。同样，@Service类只能通过接口访问其他@Service类，并且只能访问一组特定的@Repository类。

- Luiggi Mendoza

---

你（或任何人）有关于那个答案的文档或有用链接吗？ - Adrien Brunelat

我经常需要在一个服务中使用另一个服务，这可能会导致代码看起来很混乱。在Spring中是否有最佳实践来组织这些服务？例如，将某种类型的服务（可以访问其他服务的服务）放在其他服务的上一层。 - why_vincent

@why_vincent 不是这样的。但是那个设计是首选的。我认为设计应该遵循GRASP和SOLID原则，更注重这一点，而不是一个@Service调用多个@Service或者其他方面的问题。 - Luiggi Mendoza

@Luiggi Mendoza 感谢您的回答。为什么您只能通过接口而不是接口实现在控制器中访问服务？ - Ana Sustic

@AnaSustic 它专注于松耦合。例如，你发现某个操作很慢，是由于服务的实现方式所致。你可以创建一个符合当前接口的新实现，然后执行应用程序两次，一次使用当前服务接口实现，另一次使用新的实现。然后你就可以获得性能结果（吞吐量或用户负载，取决于你测量的内容），并在不影响应用程序中其余组件的情况下选择最佳方案。 - Luiggi Mendoza

Answer 2

许多人会建议将业务逻辑添加到服务层。我个人认为这不是一个好主意，特别是在开始测试时：您可能不得不同时处理持久性和业务逻辑，或者模拟周围的所有内容，然后事情可能会变得非常混乱。

在做出任何结论之前，请阅读本文： Spring Web应用程序中最大的缺陷

总之，想法是将业务逻辑移动到模型层并简化服务方法。

- Gigi

Answer 3

通常，您的业务逻辑放在服务层中。虽然您可以使用JSR注释在您的POJO中放置基本验证规则。

对于Spring MVC应用程序，您有控制器来处理HTTP请求和领域层，这是表示业务模型的POJO。您通常还有一个持久化层或DAO。您可能还有一个服务层，用于帮助处理非平凡逻辑。

关于数据库处理的评论没有意义。业务规则与存储数据无关。您的数据库处理应该放在持久化层中。

- Neil McGuigan

---

我不确定“数据库处理”是否是正确的术语，但我有一个任务，必须填充数据库中其他表的数据。 - Mark Vincent Osea