MVC是什么?
接下来,我们以登录作为一个最简单的例子,来看看不同的年代,我们是怎么写Web程序的 在很多年前,我们这么写程序的 很多年前,那是一个贫苦的年代,如果我们要使用Java在网页上做一些动态的交互功能。很多人会告诉你一个技术,叫做JSP。在我还对Java非常困惑的时候,就有人告诉我,JSP是个好东西,它可以在HTML代码里面写Java代码来完成逻辑。 Html代码
- <%
- String name = request.getParameter("name");
- String password = request.getParameter("password");
- UserHandler userHandler = new UserHandler();
- if(userHandler.authenticate(name, password)) {
- %>
- <p>恭喜你,登录成功</p>
- <%
- } else {
- %>
- <p>对不起,登录失败</p>
- <%
- }
- %>
作为一张JSP,它可以接收从别的JSP发送过来的登录请求,并进行处理。这样,我们不需要任何额外的配置文件,也不需要任何框架的帮忙,就能完成逻辑。
后来,我们放弃了在页面上写逻辑
后来,程序写得越来越多,我们发现,这种在HTML代码中编写Java代码来完成逻辑的方式存在着不少问题:
1. Java代码由于混杂在一个HTML环境中而显得混乱不堪,可读性非常差。一个JSP文件有时候会变成几十K,甚至上百K。要找一段逻辑,经常无法定位。
2. 编写代码时非常困惑,不知道代码到底应该写在哪里,也不知道别人是不是已经曾经实现过类似的功能,到哪里去引用。
3. 突然之间,某个需求发生了变化。于是,每个人蒙头开始全程替换,还要小心翼翼的,生怕把别人的逻辑改了。
4. 逻辑处理程序需要自己来维护生命周期,对于类似数据库事务、日志等众多模块无法统一支持。
在这个时候,如果有一个产品,它能够将页面上的那些Java代码抽取出来,让页面上尽量少出现Java代码,该有多好。于是许多人开始使用servlet来处理那些业务逻辑。 Java代码
- public class LoginServlet extends HttpServlet {
- /* (non-Javadoc)
- * @see javax.servlet.http.HttpServlet#doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
- */
- @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.demo2do.servlet.LoginServlet
- </servlet-class>
- </servlet>
- <servlet-mapping>
- <servlet-name>Login</servlet-name>
- <url-pattern>
- /Login
- </url-pattern>
- </servlet-mapping>
代码重构到这里,我们发现,其实我们的工作量本身并没有减少,只是代码从JSP移动到了Servlet,使得整个流程看上去稍微清楚了一些。然而,为了这么点干净,我们付出的代价是什么?为每个servlet都在web.xml里面去做一个url的请求配置!
再后来,出现框架
时代进一步发展,人们发现简单的JSP和Servlet已经很难满足人们懒惰的要求了。于是,人们开始试图总结一些公用的Java类,来解决Web开发过程中碰到的问题。这时,横空出世了一个框架,叫做struts。它非常先进地实现了MVC模式,成为了广大程序员的福音。
struts的代码示例我就不贴了,网上随便搜搜你可以发现一堆一堆的。在一定程度上,struts能够解决web开发中的职责分配问题,使得显示与逻辑分开。不过在很长一段时间内,使用struts的程序员往往无法分别我们到底需要web框架帮我们做什么,我们到底需要它完成点什么功能?
我们到底要什么
在回顾了我们写代码的历史之后,我们回过头来看看,我们到底要什么? 无论是使用JSP,还是使用Struts1,或是Struts2,我们至少都需要一些必须的元素(如果没有这些元素,或许我还真不知道这个程序会写成什么样子):
1. 数据
在这个例子中,就是name和password。他们共同构成了程序的核心载体。事实上,我们往往会有一个User类来封装name和password,这样会使得我们的程序更加OO。无论怎么说,数据会穿插在这个程序的各处,成为程序运行的核心。
2. 页面展示
在这个例子中,就是login.jsp。没有这个页面,一切的请求、验证和错误展示也无从谈起。在页面上,我们需要利用HTML,把我们需要展现的数据都呈现出来。同时我们也需要完成一定的页面逻辑,例如,错误展示,分支判断等等。
3. 处理具体业务的场所 在这里,不同阶段,处理具体业务的场所就不太一样。原来用JSP和Servlet,后来用Struts1或者Struts2的Action。 上面的这些必须出现的元素,在不同的年代,被赋予了不同的表现形式,有的受到时代的束缚,其表现形式非常落后,有的已经不再使用。但是拨开这些外在的表现形式,我们就可以发现,这不就是我们已经熟门熟路的MVC嘛? 数据 ———— Model 页面展示 ———— View 处理具体业务的场所 ———— Control 所以,框架不重要,概念是王道。只要能够深刻理解MVC的概念,框架对你来说,只是一个jar包而已。 MVC的概念其实就那么简单,这些概念其实早已深入我们的内心,而我们所缺乏的是将其本质挖掘出来。我们来看看下面这幅图,这是一副流行了很多年的讲述MVC模型的图:
在这幅图中,MVC三个框框各司其职,结构清晰明朗。不过我觉得这幅图忽略了一个问题,就是数据是动的,数据在View和Control层一旦动起来,就会产生许多的问题: 1. 数据从View层传递到Control层,如何使得一个个扁平的字符串,转化成一个个生龙活虎的Java对象 2. 数据从View层传递到Control层,如何方便的进行数据格式和内容的校验? 3. 数据从Control层传递到View层,一个个生龙活虎的Java对象,又如何在页面上以各种各样的形式展现出来 4. 如果你试图将数据请求从View层发送到Control层,你如何才能知道你要调用的究竟是哪个类,哪个方法?一个Http的请求,又如何与Control层的Java代码建立起关系来? 除此之外,Control层似乎也没有想象中的那么简单,因为它作为一个控制器,至少还需要处理以下的问题: 1. 作为调用逻辑处理程序的facade门面,如果逻辑处理程序发生了异常,我们该如何处理? 2. 对于逻辑处理的结果,我们需要做怎么样的处理才能满足丰富的前台展示需要? 这一个又一个问题的提出,都基于对MVC的基本概念的挖掘。所以,这些问题都需要我们在写程序的时候去一一解决。说到这里,这篇文章开头所提的问题应该可以有答案了:框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的。不同的框架,都是为了解决不同的问题,但是对于程序员而言,他们只是jar包而已。框架的优缺点的评论,也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以,千万不要为了学习框架而学习框架,而是要为了解决问题而学习框架,这才是一个程序员的正确学习之道。
以前一直无法舒坦的理解,MVC模式是怎样实际应用到一个程序上的。
这两天因为工作google出一幅图,然后恍然大悟。
图1.
问题就出在以前所看过的文章上根本没有提过browser这层。导致我无法正确理解view的责任、controller的责任,以及两者明明是分层的,为什么却是循环依赖。
我将browser介入其中,重新思考MVC模式究竟如何部署到程序结构上。
图2.
计算机前的用户,只会和browser打交道,也就是整个应用程序的界面部署,各种窗口,包括菜单、按钮、子对话框等等。
我把整个界面部署的代码,全部放置到browser模块下。此时无需model、view、controller,仅有browser的代码,我们就可以给用户显示这个界面。
接下来我引入model模块,这个模块的代码和窗口无关、和控件无关、和HWND无关。就是一个后台运行的东西,不需要面向任何用户。
model包含了业务的本质数据结构和逻辑流程。
然后我引入view模块,view模块代码的责任就是,如何利用browser显示model的内容。
这个责任有两个潜在意义:
1. browser模块的代码不会去访问model模块的内容,并显示在browser相应的窗口上。
2. 在没有controller的情况下——用户不能操作程序界面上的任何菜单、按钮,只能看不能摸,view模块能够在browser上给用户显示model的内容。
因此,view模块在MVC模式中所能做的就是:
1. 访问model模块,获取内容。
2. 访问browser模块,修改窗口。
最后引入controller模块。
用户在计算机前看着browser,浏览业务数据,他肯定会做一些操作,比如按下按钮,选个菜单或者其他什么的。
用户修改model模块的每一个决定性操作,就映射在controller模块的一个接口上。controller模块的责任是,代表用户的每一个动作,并分解为多个view做什么,model做什么的调用。这个动作必须有操作model或者view的代码,不然这个动作放在browser模块下就可以了。
现在合起来分析个例子,用户通过browser向model添加一个任务。
按下确定按钮后,browser读取其他子窗口的输入数据,当做参数传递给controller模块对应的调用。
l controller模块不会主动的从browser中的控件中读取数据。如果用户的动作足够简单,controller有可能就仅仅作为一个中间层调用model模块。
controller模块将用户的动作分解为一些更细致的调用:
1. 让model添加新任务。(不关心model怎么做)
2. 从model中获取新任务的信息。
3. 将新任务的信息传递给view,让他在browser显示出来。(不关心view怎么做)
从controller的动作分解中可以看出:
l 和之前view直接访问model获取数据不一样,这里controller从model获取数据,并交给view。仅由controller访问model是有好处的,使得view和model没有了耦合。
l 这里有一个微妙的循环依赖关系,browser依赖于controller,controller依赖于view,view又依赖于browser。
l 解开这一依赖的方法1,提取一个view interface,让controller依赖于他,而不是依赖于view。提取controller interface也是同理。
l 方法2,controller不依赖于view,让view自己负责根据model的状态改变显示,即controller负责修改model,view负责读取model。
l 不过,view和model之间通过controller传递数据是有好处的,除了耦合之外,另一个关键的地方是,可以在controller中过滤数据,而不用修改model。
l 这两个方法没有最好,只有根据具体的情况选择最合适的做法。在程序足够小的情况下,其实是不需要把模块划分得那么清楚的