三大框架SSH与MVC的设计模式
Posted 广东金融IT课程学习
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了三大框架SSH与MVC的设计模式相关的知识,希望对你有一定的参考价值。
MVC是一个框架模式,它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP + servlet + javabean的模式。
视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说,视图就是由html元素组成的界面,在新式的Web应用程序中,HTML依旧在视图中扮演着重要的角色,但一些新的技术已层出不穷,它们包括Adobe Flash和像XHTML,XML/XSL,WML等一些标识语言和Web services.
MVC好处是它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生,不管这些数据是联机存储的还是一个雇员列表,作为视图来讲,它只是作为一种输出数据并允许用户操纵的方式。
模型
模型表示企业数据和业务规则。在MVC的三个部件中,模型拥有最多的处理任务。例如它可能用像EJBs和ColdFusion Components这样的构件对象来处理数据库,被模型返回的数据是中立的,就是说模型与数据格式无关,这样一个模型能为多个视图提供数据,由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性
控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求,所以当单击Web页面中的超链接和发送HTML表单时,控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求,然后再确定用哪个视图来显示返回的数据。
SSH
集成SSH框架的系统从职责上分为四层:表示层、业务逻辑层、数据持久层和域模块层,以帮助开发人员在短期内搭建结构清晰、可复用性好、维护方便的Web应用程序。其中使用Struts作为系统的整体基础架构,负责MVC的分离,在Struts框架的模型部分,控制业务跳转,利用Hibernate框架对持久层提供支持,Spring做管理,管理struts和hibernate。具体做法是:用面向对象的分析方法根据需求提出一些模型,将这些模型实现为基本的Java对象,然后编写基本的DAO(Data Access Objects)接口,并给出Hibernate的DAO实现,采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问,最后由Spring做管理,管理struts和hibernate。
系统的基本业务流程是: 在表示层中,首先通过JSP页面实现交互界面,负责接收请求(Request)和传送响应(Response),然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。在业务层中,管理服务组件的Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中,则依赖于Hibernate的对象化映射和数据库交互,处理DAO组件请求的数据,并返回处理结果。
采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化,模型层只需很少的改动,并且数据库的变化也不会对前端有所影响,大大提高了系统的可复用性。而且由于不同层之间耦合度小,有利于团队成员并行工作,大大提高了开发效率。
MVC与SSH的区别
MVC三层架构:模型层,控制层和视图层。模型层,用Hibernate框架让来JavaBean在数据库生成表及关联,通过对JavaBean的操作来 对数据库进行操作;控制层,用Struts框架来连接数据层和视图层的,接收、处理、发送数据并控制流程;视图层,用JSP模板把页面展现给用户以及提供 与用户的交互。而Spring框架粘合了Hibernate和Struts,透明的管理了整个架构,提供IOC容器使代码松耦合以及AOP框架的切面功能 等等。
也可以换种说法:我们去饭馆吃饭,摆在我们面前的油淋小白菜就是Jsp呈现的视图,而这道菜怎么来的呢,当然要有小白菜,也就是Hibernate产生的 数据,小白菜要洗干净,切好,这是对数据的操作;这些准备好了就要炒小白菜了,这就是Struts的事了。这个过程分工明确,各做各的,有的只负责洗菜, 有的只负责炒菜的,Spring就是中间负责跑腿的,让洗菜的和炒菜的都安心做自己的事。最终一道菜就出来了,我们看到的是成品菜,却看不见它被制作的过 程。
自己的体会:
MVC是一种框架模式,是一种思想,SSH是一种框架,是框架模式的实现,SSH是一种经典的MVC模式。
SSH是指struts2、spring、hibernate,是三种被封装的框架。MVC是指Model、view、control,是程序的一种分层模式。SSH是一种经典的MVC模式。
现在许许多多的初学者和程序员,都在趋之若鹜地学习Web开发的宝典级框架:Struts2,
Spring,Hibernate。似乎这些框架成为了一个人是否精通Java,是否会写J2EE程序的唯一事实标准和找工作的必备基础。
然而,如果在面试的时候问这些程序员,你们为什么要学习这些框架?这些框架的本质到底是什么?似乎很少很少有人能够给我非常满意的答复。因为他们都在为了学习而学习,为了工作而学习,而不是在真正去深入了解一个框架。其实所有的人都应该思考这样的问题:为什么要学习框架?框架到底给我带来了什么?接下来,我们以登录作为一个最简单的例子,来看看不同的年代,我们是怎么写Web程序的。
后来,我们放弃了在页面上写逻辑。
后来,程序写得越来越多,我们发现,这种在HTML代码中编写Java代码来完成逻辑的方式存在着不少问题:
1. Java代码由于混杂在一个HTML环境中而显得混乱不堪,可读性非常差。一个JSP文件有时候会变成几十K,甚至上百K。要找一段逻辑,经常无法定位。
2. 编写代码时非常困惑,不知道代码到底应该写在哪里,也不知道别人是不是已经曾经实现过类似的功能,到哪里去引用。
3. 突然之间,某个需求发生了变化。于是,每个人蒙头开始全程替换,还要小心翼翼的,生怕把别人的逻辑改了。
4. 逻辑处理程序需要自己来维护生命周期,对于类似数据库事务、日志等众多模块无法统一支持。
在这个时候,如果有一个产品,它能够将页面上的那些Java代码抽取出来,让页面上尽量少出现Java代码,该有多好。于是许多人开始使用servlet来处理那些业务逻辑。
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的请求关系。
<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的请求配置!
在很多年前,我们这么写程序的。
很多年前,那是一个贫苦的年代,如果我们要使用Java在网页上做一些动态的交互功能。很多人会告诉你一个技术,叫做JSP。在我还对Java非常困惑的时候,就有人告诉我,JSP是个好东西,它可以在HTML代码里面写Java代码来完成逻辑。
<%
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发送过来的登录请求,并进行处理。这样,我们不需要任何额外的配置文件,也不需要任何框架的帮忙,就能完成逻辑。
再后来,出现框架。
时代进一步发展,人们发现简单的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包而已。框架的优缺点的评论,也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以,千万不要为了学习框架而学习框架,而是要为了解决问题而学习框架,这才是一个程序员的正确学习之道。
以上是关于三大框架SSH与MVC的设计模式的主要内容,如果未能解决你的问题,请参考以下文章