接上一篇《详解 MVC、MVC 框架、MVC 模式、Spring MVC》，我们进行 model2 架构的缺点。
更多精彩内容请看 web 前端中文站
http://www.lisa33xiaoq.net 可按 Ctrl + D 进行收藏
从前文中的 Model2 架构可以看出，视图和模型分离了，控制逻辑和展示逻辑分离了。
但我们也看到严重的缺点：
控制器
- 控制逻辑可能比较复杂，其实我们可以按照规约，如请求参数 submitFlag=toAdd，我们其实可以直接调用 toAdd 方法，来简化控制逻辑；而且每个模块基本需要一个控制器，造成控制逻辑可能很复杂；
- 请求参数到模型的封装比较麻烦，如果能交给框架来做这件事情，我们可以从中得到解放；
- 选择下一个视图，严重依赖 Servlet API，这样很难或基本不可能更换视图；
- 给视图传输要展示的模型数据，使用 Servlet API，更换视图技术也要一起更换，很麻烦。
模型
此处模型使用 JavaBean，可能造成 JavaBean 组件类很庞大，一般现在项目都是采用三层架构，而不采用 JavaBean。
视图
现在被绑定在 JSP，很难更换视图，比如 Velocity、FreeMarker；比如我要支持 Excel、PDF 视图等等。
服务到工作者：Front Controller + Application Controller + Page Controller + Context
即，前端控制器+应用控制器+页面控制器（也有称其为动作）+上下文，也是 Web MVC，只是责任更加明确。
运行流程如下：
- Front Controller：前端控制器，负责为表现层提供统一访问点，从而避免 Model2 中出现的重复的控制逻辑（由前端控制器统一回调相应的功能方法，如前边的根据 submitFlag=login 转调 login 方法）；并且可以为多个请求提供共用的逻辑（如准备上下文等等），将选择具体视图和具体的功能处理（如 login 里边封装请求参数到模型，并调用业务逻辑对象）分离。
- Application Controller：应用控制器，前端控制器分离选择具体视图和具体的功能处理之后，需要有人来管理，应用控制器就是用来选择具体视图技术（视图的管理）和具体的功能处理（页面控制器/命令对象/动作管理），一种策略设计模式的应用，可以很容易的切换视图/页面控制器，相互不产生影响。
- Page Controller(Command)：页面控制器/动作/处理器：功能处理代码，收集参数、封装参数到模型，转调业务对象处理模型，返回逻辑视图名交给前端控制器（和具体的视图技术解耦），由前端控制器委托给应用控制器选择具体的视图来展示，可以是命令设计模式的实现。页面控制器也被称为处理器或动作。
- Context：上下文，还记得 Model2 中为视图准备要展示的模型数据吗，我们直接放在 request 中（Servlet API 相关），有了上下文之后，我们就可以将相关数据放置在上下文，从而与协议无关（如 Servlet API）的访问/设置模型数据，一般通过 ThreadLocal 模式实现。
到此，我们回顾了整个 web 开发架构的发展历程，可能不同的 web 层框架在细节处理方面不同，但的目的是一样的：
干净的 web 表现层，模型和视图的分离，控制器中的控制逻辑与功能处理分离（收集并封装参数到模型对象、业务对象调用），控制器中的视图选择与具体视图技术分离。
轻薄的 web 表现层，做的事情越少越好，薄薄的，不应该包含无关代码；只负责收集并组织参数到模型对象，启动业务对象的调用；控制器只返回逻辑视图名并由相应的应用控制器来选择具体使用的视图策略；
尽量少使用框架特定 API，保证容易测试。
【注：本文源自网络文章资源，由站长整理发布】
