尽量减少控制器责任
理想情况下，Spring MVC应用程序中的控制器必须接收请求，将请求发送到API，将（调用的）结果加载到模型上（对于视图随后呈现它）并转发到视图。 他们不应该再做了。
我的控制器今天所做的远不止这些，我想将某些重要性从控制器转移到其他API。 我今天的应用程序设计（非常典型）：
controller Service API DAO DB 今天的控制器填补了Web应用程序需要的内容和Service API提供的内容之间的差异。 我想在控制器和服务API之间放置额外的层/层，以便在这个delta处咀嚼。 我的问题是这些层应该是什么层以及这些新层的责任应该是什么？
我目前的想法如下
controller controller helper Business API Service API DAO DB
控制器助手（Web上下文感知 – 将依赖于Model，HttpServlet和其他Web上下文类）：
- 将实体转换为DTO对象（2路）
- 将ID解析为实体。 例如，Controller查找学生ID（使用密钥）并将其转换为Student实体。
Business API（没有Web上下文依赖 – 可以通过JUnit测试）：
- 充当门面。 调用多个服务API以实现一个业务请求。
- 提供专门用于Web应用程序的API。
你会以不同的方式解决这个问题吗？ 是否有与此特定问题相关的资源（书籍，文章等）？
之前的一些讨论没有回答我的问题：
设计mvc控制器层
服务层=应用层= GRASP控制器层
移动validation，Html助手到MVC中的服务层
谢谢，维杰
服务包含应用程序的一般业务逻辑。 它们几乎是控制器和DAO / DB之间的任何东西。
您的“业务层”和“控制器助手”只是更多的服务。 为了简单起见，我会保留经典设计：
Controllers <-> possible Services <-> possible DAOs <-> DB
如果我有很多服务（我通常不会）碰巧执行相同类型的逻辑，我自然会将它们分成子包。 例如 ：
- services.facade或services.business
- 用于DTO的services.adapter（除非你使用简单的类来完成这项工作）
控制器调用外观服务，例如： someFacade.someMethod(SomeDTO someDto) 。 然后，由于其他服务（或简单的类），外观处理DTO < - >实体转换。
这就是我在你的背景下会做的。 在理想的世界中（没有遗留系统，或从头开始的项目），我直接使用实体作为表单对象（而不是DTO），我的大多数服务都是外观（其余的将是简单的类，如果可能的话） ）。
我是Spring MVC的新手，也面临着这种困境。 虽然Spring对我来说很新，但我已经和MVC合作了好几年了。 我同意控制器应该只接受请求，发送它们，并以正确的格式呈现结果。 我认为服务不一定是帮助抽象存在的最佳位置。 我相信一个服务应该封装一个特定的API，不做任何其他事情。 我觉得创造许多“类型”的服务使这种模式变得令人厌恶，并且不清楚责任落在何处。
我相信帮助者更适合作为服务的兄弟姐妹; 它们应该用@Component而不是@Service来修饰。 它们的作用是充当底层API的外观，这些API是在通过端点公开的模型上转换状态所需的。 Controller-> Helper – > [Services]模式促进了关注点的清晰分离，代码可重用性，并且具有高度的可测试性。 这种模式的本质是防止控制器膨胀，因此你最终得到的超薄控制器除了调度请求和呈现响应之外什么都不做。