java - 最小化 Controller 责任

Question

理想情况下，Spring MVC 应用程序中的 Controller 必须接收请求、将请求发送到 API、将(调用的)结果加载到模型(以便 View 随后呈现它)并转发到 View 。他们不应该再做了。

我的 Controller 现在做的远不止这些，我想将某些职责从 Controller 转移到其他 API。我今天的应用程序设计(非常典型):

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

今天的 Controller 填补了网络应用程序需要的内容和服务 API 提供的内容之间的差异。 我想在 Controller 和服务 API 之间放置额外的层，以消除这个增量。我的问题是这些层应该是什么层以及这些新层的职责是什么？

我目前的思路如下

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

Controller 助手(网络上下文感知 - 将取决于模型、HttpServlet 和其他网络上下文类):

1. 将实体转换为 DTO 对象(两种方式)
2. 将 ID 解析为实体。例如。 Controller 查找学生 ID。 (使用 key )并将其转换为学生实体。

业务 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

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

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

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

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

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

外观服务由 Controller 调用，如下所示:someFacade.someMethod(SomeDTO someDto)。然后由于其他服务(或简单类)，外观处理 DTO <-> 实体转换。

在您的情况下，我会这样做。在一个理想的世界中(没有遗留系统，或者在从头开始的项目中)，我会直接使用实体作为表单对象(而不是 DTO)，并且我的大部分服务都是外观(如果可能的话，其余的将是简单的类).