我的MVC困惑-----读<MVC框架的困惑>有感

 

我的MVC困惑

                                                                                                                                          -----08/06/2010

 

今天颇有时间，便抽这正午时分，写下《我的MVC困惑》。当然本文观点仅是个人立场，并非名门正道，其中必有糟粕，然请读者择其善者而习之，切勿盲目侍从。一种观点被提出，有道贺满堂的，当然也少不了辱骂满街的。惹尔阅此文后，与吾不谋而合，那当然是好，倘若相反，也请尔勿对吾进行人生攻击。

                                                                                                                                            

         在51job.com、zhaopin.com和chinahr.com等大型招聘网站上，你可以看在招聘软件程序员的要求里，总有这么一条：“熟练掌握Struts,Hibernate,Spring等开发技术”。似乎SSH这些框架成为了一个人是否精通Java，是否能胜任Java EE的唯一标准和找工作的必备基础。

 

         所以导致了一种业内现象，现在有不计其数的程序员在盲目的学习这些框架，请注意，我用的是“盲目”，这个让人想对我观点进行反驳的字眼。为什么用盲目来形容现在的状况呢？有人说我是不是太极端啦！那好，问你几个问题：你为什么要学习这些框架？这些框架的本质是什么？你能理直气壮地告诉我吗？似乎很少人能非常自信地回答这些问题。因为我们是在为了工作的需要在学习它们，为了简历多了几项技能，而很少去真正的感受这些框架的本质，扪心自问，学它们来干吗？为什么工作要用它们？用在哪里？

 

         大学初学Java EE的时候，我们学习了JSP技术，是程序是这样的：

Html代码 

 

 

 

1.  <%  

2.       String name = request.getParameter("name");  

3.       String password = request.getParameter("password");  

4.    

5.       UserHandler userHandler = new UserHandler();  

6.       if(userHandler.authenticate(name, password)) {  

7.  %>  

8.  <p>恭喜你，登录成功</p>  

9.  <%  

10.       } else {  

11. %>  

12. <p>对不起，登录失败</p>  

13. <%  

14.       }  

15. %>

这是一个完全由JSP来完成逻辑处理的，即在HTML里嵌入Java来实现的！！！

但是后来老师告诉我们说，单凭JSP写成的程序不好，它的可读性差，可维护性差，层次性差等前人SUN公司没有想到的都被想出来了！

 

接着又随着老师学习了Servlet技术。Servlet本质就是把放在HTML文件里的Java代码抽取出来放在一个纯.java文件里，然后用web.xml文件来配置servlet，与请求达成关系。

Java代码 

 

 

1.  public class LoginServlet extends HttpServlet {  

2.    

3.      /* (non-Javadoc) 

4.       * @see javax.servlet.http.HttpServlet#doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) 

 

5.       */  

6.      @Override  

7.      protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { 

 

8.          String message = null;  

9.          RequestDispatcher dispatcher = req.getRequestDispatcher("/result.jsp");  

10.         String name = req.getParameter("name");  

11.         String password = req.getParameter("password");  

12.           

13.         UserHandler userHandler = new UserHandler();  

14.         if(userHandler.authenticate(name, password)) {  

15.             message = "恭喜你，登录成功";  

16.         } else {  

17.             message = "对不起，登录失败";  

18.         }  

19.           

20.         req.setAttribute("message", message);  

21.         dispatcher.forward(req, resp);  

22.     }  

23. }  

 

Xml代码 

1.  <servlet>  

2.    <servlet-name>Login</servlet-name>  

3.      <servlet-class>  

4.        com.demo2do.servlet.LoginServlet  

5.    </servlet-class>  

6.  </servlet>  

7.  <servlet-mapping>  

8.    <servlet-name>Login</servlet-name>  

9.    <url-pattern>  

10.     /Login  

11.   </url-pattern>  

12. </servlet-mapping>  

 

Servlet这样做也有好处的，可读性加强了，层次性加强了，也较可维护了，但是代码重构性还是太差了

 

于是为了达到DRY(Don’t Repeat Yourself)原则,即加强代码重构性。出现了好多好多的框架啦。所以，我们要开始学习各种不同的框架了，可是学了一段时间后，我们不知道到底需要框架来帮我们完成什么功能？

 

 

 

 

 

下面采用JAVAEYE的一位我敬佩的作者的文章来诠释吧：

 

 

在回顾了我们写代码的历史之后，我们回过头来看看，我们到底要什么？ 

无论是使用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包而已。框架的优缺点的评论，也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以，千万不要为了学习框架而学习框架，而是要为了解决问题而学习框架，这才是一个程序员的正确学习之道。

 

评论

1 楼 liangcoder 2010-08-06  

"框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的"
确实是这个道理，如果没有真实的遇到这些问题，很难真正理解框架所提供的功能。