spring mvc框架中业务逻辑放在哪里？答案

【问题标题】：Where to put business logic in spring mvc framework?spring mvc框架中业务逻辑放在哪里？
【发布时间】：2014-10-10 21:34:31
【问题描述】：

我不知道在 spring mvc 中将业务逻辑放在哪里，因为我是新手。我知道该怎么做，但由于缺乏对 spring mvc 的了解，我不知道从哪里开始。我还想问一下是否有人知道我在哪里可以获得关于此的好教程或具有业务逻辑的 spring mvc Web 应用程序的完整示例？无论如何，我所说的业务逻辑都是关于数据库处理的:)

【问题讨论】：

标签： java spring-mvc business-logic

【解决方案1】：

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

@Service 类应该为您的服务层服务。 你应该把你的业务逻辑放在这里。

@Repository 类应该为您的数据访问层服务。此处应放置 CRUD 逻辑：插入、更新、删除、选择。

@Service、@Repository 并且您的实体类将是 来自 MVC 的 M。 JSP 和其他视图技术（例如 JSP、Thymeleaf 等）将符合 MV 中的 V。

@Controller 类只能通过接口访问@Service 类。类似地，@Service 类应该只能通过接口访问其他@Service 类和一组特定的@Repository 类。

【讨论】：

您（或任何人）是否有指向该答案的文档或有用链接的链接？
我经常发现自己需要使用其他服务中的服务。这很容易最终看起来很混乱。春天有什么首选的方式来安排这个吗？比如在服务的其余部分之上有一个特定类型的服务（Service-that-can-access-services）。
@why_vincent 不是。但这种设计是首选。我认为设计应该遵循 GRASP 和 SOLID，而不是 @Service 调用许多 @Services 或注释。
@Luiggi Mendoza 感谢您的回答。为什么只能通过接口而不是接口实现来访问Controller中的Service？
@AnaSustic 它专注于松散耦合。举个例子，假设您发现某个特定的操作很慢，这与服务的实现方式有关。您可以创建一个符合当前接口的新实现，然后执行应用程序两次，一次使用当前服务接口实现，另一次使用新服务接口实现。然后，您可以获得性能结果（吞吐量或用户负载，取决于您测量的内容）并选择最佳而不影响应用中的其余组件。

【解决方案2】：

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

我确实建议在得出任何结论之前阅读这篇文章： The Biggest Flaw of Spring Web Applications

重新开始，我们的想法是将业务逻辑移至模型层并简化您的服务方法。

【讨论】：

【解决方案3】：

通常，您的业务逻辑位于服务层。虽然您可以使用 JSR 注释将基本验证规则放入您的 pojo。

对于 Spring MVC 应用程序，您具有处理 http 请求的控制器和域层，它们是代表您的业务模型的 pojo。您通常有一个持久层或 DAO。您可能还有一个服务层，用于帮助处理非平凡的逻辑。

您对数据库处理的评论没有意义。业务规则与存储数据是正交的。您的数据库处理应该在您的持久层中进行。

【讨论】：

我不知道数据库处理是否是正确的短语，但我有一个任务，我必须填写数据库中其他表的数据。