理想情况下，在一个Spring MVC应用控制器必须接收请求，寄发请求的API，在加载结果（的调用）到模型（用于视图随后使它）并转发到的视图。 他们应该做的不多。
我做的控制器远不止这个今天，我想从控制器到其他的API移开一定resposibilities。 我今天的（非常典型的）应用程序设计：
controller <-> Service API <-> DAO <-> DB
今天控制器填补了哪些Web应用程序需要什么服务API提供之间的增量。 我想放置控制器和服务的API，在此增量咀嚼远之间的额外层/层。 我的问题是什么层（一个或多个）应这些是什么应将这些新层（S）的职责是什么？
我现在的想法是如下
controller <-> controller helper <-> Business API <-> Service API <-> DAO <-> DB
控制器助手（网络情境感知 - 将取决于模型的HttpServlet和其他网络上下文类）：
- 转换实体DTO对象（2路）
- ID解析为实体。 如控制器查学生证（使用键）并将其转换为一个学生的实体。
商务API（没有网络语境依赖性 - 可JUnit的测试）：
- 充当门面。 调用多个服务API来实现一个业务请求。
- 提供专门量身定制。针对web应用程序的API。
你会解决这个问题以不同的方式？ 是否有关于这个具体问题的任何资源（书籍，文章等）？
以前的一些讨论认为没有回答我的问题：
设计MVC控制器层
服务层=应用层= GRASP控制器层
移动验证，HTML辅助，以服务MVC层
谢谢，维杰
服务包含应用程序的通用业务逻辑。 他们是控制器和DAO / DB之间的几乎任何东西。
您的“业务层”和“控制器助手”只是更多的服务。 我会保持经典设计为简单起见：
Controllers <-> possible Services <-> possible DAOs <-> DB
如果我有很多的服务（我通常不）是发生在执行同一种逻辑的，我会自然地将它们分为子包。 例如 ：
- services.facade，或services.business
- services.adapter的DTO的（除非你用简单的类来完成这一工作）
：阿立面服务是由像这样的控制器称为someFacade.someMethod(SomeDTO someDto) 然后门面处理DTO < - >实体的转换由于其他服务（或简单的类）。
这就是我怎么会在你的情况下做的。 在一个理想的世界（不遗留系统，或者从头开始一个项目），我会直接用实体表单对象（而不是DTO的），以及我的大多数服务将是外墙（其余的将是简单的类，如果可能的话）。
我是新来的Spring MVC和我也面临着这种困境。 虽然春天是新的给我，我一直使用MVC了好几年。 我同意控制器应该做的并不比接受请求，派遣他们更多的，并呈现以正确的格式的结果。 我是一个服务并不一定是辅助抽象虽然存在最好的地方的意见的。 我相信，一个服务应该封装特定的API，什么也不做更多。 我觉得自己创造了许多服务的“类型”卷积，这种模式并使其目前还不清楚其中的责任回落。
这是我的信念，助手更适合作为兄弟服务; 他们应该@Component而不是@Service装饰。 它们的作用是充当对于那些需要通过端点暴露模型过渡态的底层API的一个门面。 所述控制器 - >辅助 - > [服务]图案促进顾虑，代码的可重用性的明确分离，并且是高度可测试的。 这种模式的本质是阻止控制器膨胀，所以你最终以超薄控制器，真正做无非调度请求和渲染响应。
