尽量减少控制器责任

Question

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

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

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

控制器今天填补了哪些Web应用程序需要什么服务API提供之间的增量。 我想在控制器和服务API之间放置额外的层/层，以消除这个增量。我的问题是这些层应该是什么层，这些新层的责任是什么？

我现在的想法如下

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

控制器助手（网络情境感知 - 将取决于模型的HttpServlet和其他网络上下文类）：

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

业务API（没有网络语境依赖性 - 可JUnit的测试）：

1. 充当门面。调用多个服务API来实现一个 业务请求。
2. 提供专门针对Web应用程序的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
• services.adapter的DTO的（除非你用简单的类来完成这一工作）

的立面服务由控制器称为像这样：someFacade.someMethod(SomeDTO someDto)。然后，门面处理DTO < - >实体转换感谢其他服务（或简单的类）。

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

Answer 2

我是Spring MVC的新手，也面临着这个困境。尽管Spring对我来说是新手，但我一直在与MVC合作多年。我同意一个控制者不应该只接受请求，发送它们，并以正确的格式呈现结果。我认为服务并不一定是帮助者抽象存在的最佳位置。我相信一个服务应该封装一个特定的API并且别无所求。我觉得创建许多“服务类型”会影响这种模式，并且不清楚责任落在哪里。

我相信助手更适合作为兄弟姐妹来服务;他们应该用@Component而不是@Service来装饰。他们的角色是充当底层API的外观，这些底层API需要在通过端点公开的模型上过渡状态。 Controller-> Helper - > [Services]模式促进了问题的清晰分离，代码可重用性，并且是高度可测试的。这种模式的本质是为了防止控制器膨胀，所以你最终得到的超薄控制器除了派遣请求和渲染响应之外无非是。