东汉末年分三国 MVC模式的演进
许许多多的 java 初学者和程序员，都在趋之若鹜地学习 JavaWeb 开发的经典三大框架：无论是 SSH（Struts2，Spring，Hibernate） 还是 SSM（Spring，SpringMVC，Mybatis）似乎这些框架成为了一个人是否精通 Java，是否会写 JavaEE 程序的唯一事实标准和找工作的必备基础。
然而，很多人只是单纯为了学习而学习，为了工作而学习，并没有多少人想去深入了解一个框架。其实所有的人都应该思考这样的问题：为什么要学习框架？框架到底给我带来了什么？
其实这些框架都是在开发过程中，不断 迭代 重构 总结 出的”套路”，是一套约定俗成的设计方式。
让我们回顾过去的历史，看一下 MVC 的演化过程，希望能帮助你更好的理解 MVC...
JavaEE 发展过程中经历的模式
model1模式
原始的 JSP
技术构成: JSP + JavaBean
在很多年前，那是一个贫苦的年代，要使用 Java 在网页上做一些动态的交互功能 是通过 JSP 实现的，它可以在 HTML 代码里面写 Java 代码来完成逻辑。
Html代码:
<%
String name = request.getParameter("name");
String password = request.getParameter("password");
UserHandler userHandler = new UserHandler();
if(userHandler.authenticate(name, password)) {
%>
恭喜你，登录成功
<%
} else {
%>
对不起，登录失败
<%
}
%> 作为一张 JSP，它可以接收从别的 JSP 发送过来的登录请求，并进行处理。这样，我们不需要任何额外的配置文件，也不需要任何框架的帮忙，就能完成逻辑。
弊端：随着业务的复杂性急剧增加，如果在 JSP 页面中添加大量 Java 代码，会让整个 JSP 变得十分复杂混乱，而且不容易维护
model2模式
我们放弃了在页面上写逻辑
技术组成: JSP + Servlet + JavaBean 优势: 能让各个技术发挥自己擅长的方面 JSP: 页面数据动态显示 Servlet: 处理业务逻辑,处理Java代码
程序写得越来越多，这种在 HTML 代码中编写 Java 代码来完成逻辑的方式存在着不少问题：
Java代码由于混杂在一个HTML环境中而显得混乱不堪，可读性非常差。一个JSP文件有时候会变成几十K，甚至上百K。要找一段逻辑，经常无法定位。
编写代码时非常困惑，不知道代码到底应该写在哪里，也不知道别人是不是已经曾经实现过类似的功能，到哪里去引用。
在这个时候，许多人开始使用 servlet 将页面上的那些 Java 代码抽取出来，处理那些业务逻辑。 让页面上尽量少出现Java代码，于是：
Java代码
public class LoginServlet extends HttpServlet {
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
String message = null;
RequestDispatcher dispatcher = req.getRequestDispatcher("/result.jsp");
String name = req.getParameter("name");
String password = req.getParameter("password");
UserHandler userHandler = new UserHandler();
if(userHandler.authenticate(name, password)) {
message = "恭喜你，登录成功";
} else {
message = "对不起，登录失败";
}
req.setAttribute("message", message);
dispatcher.forward(req, resp);
}
} 我们还需要在 web.xml 中为这个 servlet 配置 url的请求关系。
Xml代码
<servlet>
<servlet-name>Login</servlet-name>
<servlet-class>
com.demo.servlet.LoginServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Login</servlet-name>
<url-pattern>/Login</url-pattern>
</servlet-mapping> 其实我们的工作量本身并没有减少，只是代码从 JSP 移动到了 Servlet，使得整个流程看上去稍微清楚了一些。
model3模式
MVC
M : Model,即模型,主要作用是封装数据(JavaBean) V : View,即视图,主要作用是页面数据显示(JSP) C : Controller,即控制器,主要作用: 获取数据进行封装业务处理传递数据指定显示的页面
时代进一步发展，简单的 JSP 和 Servlet 已经很难满足人们的要求了。于是，人们开始试图总结一些公用的 Java 类，来解决 Web 开发过程中碰到的问题。这时 MVC 模式出现了，成为了广大程序员的福音。
注：MVC 不是 Java 独有 , 几乎所有 B/S 架构软件都采用（只是可能名称不同你可能听说过组件模型，也有称之为事件模型。 ）
JavaEE 三层架构 只有JavaEE采用三层架构
三层的分类
Web层: 表现层.---- 与客户端交互 Service层: 业务层 ---- 负责复杂的业务处理 Dao: 数据层(持久层) ---- 与数据库交互
我们到底要什么
在回顾了我们写代码的历史之后，我们回过头来看看，我们到底要什么？
无论是使用 JSP，还是使用 Web框架，我们至少都需要一些必须的元素：
1、数据 在这个例子中，就是name和password。他们共同构成了程序的核心载体。
2、页面展示 在这个例子中，就是 login.jsp。没有这个页面，一切的请求、验证和错误展示也无从谈起。
3、处理具体业务的场所 在这里，不同阶段，处理具体业务的场所就不太一样。原来用的 JSP 和 Servlet，后来用的Action 或 Controller…
上面的这些必须出现的元素，在不同的年代，被赋予了不同的表现形式，有的受到时代的束缚，其表现形式非常落后，有的已经不再使用。但是拨开这些外在的表现形式，我们就可以发现，这不就是我们已经熟门熟路的MVC嘛？
数据 ———— Model
页面展示 ———— View
处理具体业务的场所 ———— Control
所以，框架不重要，概念是王道。只要能够深刻理解MVC的概念，框架对你来说，只是一个jar包而已。
MVC的概念其实就那么简单，这些概念其实早已深入我们的内心，而我们所缺乏的是将其本质挖掘出来。我们来看看下面这幅图：
1、数据从 View 层传递到 Control 层，如何使得一个个扁平的字符串，转化成一个个生龙活虎的 Java对象？ 2、数据从 Control 层传递到 View 层，一个个生龙活虎的 Java对象，又如何在页面上以各种各样的形式展现出来？ 3、如果你试图将数据请求从 View 层发送到 Control 层，你如何才能知道你要调用的究竟是哪个类，哪个方法？ 4、一个Http的请求，又如何与 Control 层的 Java代码 建立起关系来？ 5、Control 作为调用逻辑处理程序的门面，如果逻辑处理程序发生了异常，我们该如何处理？ 6、对于逻辑处理的结果，我们需要做怎么样的处理才能满足丰富的前台展示需要？
这一个又一个问题的提出，都基于对 MVC 的基本概念的挖掘。所以，这些问题都需要我们在写程序的时候去一个个解决。
框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的。
不同的框架，都是为了解决不同的问题，但是对于程序员而言，他们只是jar包而已。
框架的优缺点的评论，也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以，千万不要为了学习框架而学习框架，而是要为了解决问题而学习框架，这才是一个程序员的正确学习之道。
让我们透过现象，看到本质。做好准备下次将从 Servlet 开始，重游三国历史，参悟设计思想。。。