最小化控制器责任

Question

理想情况下，Spring MVC 应用程序中的控制器必须接收请求，将请求发送到 API，将（调用的）结果加载到模型（以便视图随后呈现它）并转发到视图。他们不应该再做任何事情了。

我的控制器今天所做的远不止这些，我想将某些职责从控制器转移到其他 API。我今天的应用程序设计（非常典型）：

controller <-> Service API <-> DAO <-> DB

如今，控制器填补了 Web 应用所需的内容与服务 API 提供的内容之间的差异。 我想在控制器和服务 API 之间放置额外的层/层，以消除这个增量。我的问题是这些应该是什么层以及这些新层的职责应该是什么？

我目前的想法如下

controller <-> controller helper <-> Business API <-> Service API <-> DAO <-> DB

控制器助手（Web 上下文感知 - 将依赖于 Model、HttpServlet 和其他 Web 上下文类）：

1. 将实体转换为 DTO 对象（2 种方式）
2. 将 ID 解析为实体。例如。控制器查找学生 ID。 （使用密钥）并将其转换为 Student 实体。

业务 API（无 Web 上下文依赖 - 可以进行 JUnit 测试）：

1. 充当门面。调用多个服务 API 来实现一个 业务请求。
2. 提供专门为网络应用量身定制的 API。

你会用不同的方式解决这个问题吗？是否有与此特定问题相关的资源（书籍、文章等...）？

之前的一些讨论没有回答了我的问题：

Designing mvc controller layer

Service layer = Application layer = GRASP Controller layer

Moving Validation, Html Helpers to Service Layer in MVC

谢谢， 维杰

Answer 1

服务包含应用程序的一般业务逻辑。它们几乎是控制器和 DAO/DB 之间的任何东西。

您的“业务层”和“控制器助手”只是更多的服务。为了简单起见，我会保留经典设计：

Controllers <-> possible Services <-> possible DAOs <-> DB

如果我有很多服务（我通常不会）碰巧执行相同类型的逻辑，我自然会将它们拆分为子包。例如：

• services.facade 或 services.business
• 用于 DTO 的 services.adapter（除非您使用简单的类来完成这项工作）

外观服务由控制器调用，如下所示：someFacade.someMethod(SomeDTO someDto)。然后门面处理 DTO 实体转换，这要归功于其他服务（或简单的类）。

这就是我在你的上下文中会做的事情。在一个理想的世界中（没有遗留系统，或者从头开始的项目），我会直接使用实体作为表单对象（而不是 DTO），我的大部分服务都是门面（如果可能的话，其余的都是简单的类)。

Answer 2

我是 Spring MVC 的新手，也面临着这个困境。尽管 Spring 对我来说是新事物，但我已经使用 MVC 工作了好几年了。我同意控制器应该只接受请求、分派它们并以正确的格式呈现结果。我认为服务不一定是帮助抽象存在的最佳场所。我相信一个服务应该封装一个特定的 API 并且什么都不做。我觉得创建许多“类型”的服务会使这种模式复杂化，并不清楚责任落在哪里。

我认为助手更适合作为服务的兄弟姐妹；它们应该用@Component 而不是@Service 装饰。它们的作用是充当底层 API 的门面，这些 API 需要在通过端点公开的模型上转换状态。 Controller->Helper->[Services] 模式促进了关注点的清晰分离、代码可重用性和高度可测试性。这种模式的本质是防止控制器膨胀，因此您最终会得到超薄的控制器，实际上除了调度请求和呈现响应之外什么都不做。