当前位置:首页 > 办公文档 > 工作范文 > struts2-指南
本章要点—Web应用的发展—Model1和Model2—MVC思想—MVC模式的优势—常用MVC框架及其特征—Struts1的基本结构及其存在的问题—WebWork的基本结构—Struts2的起源—Struts2的框架架构—Struts2的标签库—Struts2的控制器组件—Struts1和Struts2的对比Struts1是全世界第一个发布的MVC框架,它由CraigMcClanahan在2001年发布,该框架一经推出,就得到了世界上JavaWeb开发者的拥护,经过长达6年时间的锤炼,Struts1框架更加成熟、稳定,性能也有了很好的保证。因此,到目前为止,Struts1依然是世界上使用昀广泛的MVC框架。目前,基于Web的MVC框架非常多,发展也很快,每隔一段时间就有一个新的MVC框架发布,例如像JSF、Tapestry和SpringMVC等。除了这些有名的MVC框架外,还有一些边缘团队的MVC框架也很有借鉴意义。对于企业实际使用MVC框架而言,框架的稳定性则应该是昀值得考虑的问题。一个刚刚起步的框架,可能本身就存在一些隐藏的问题,会将自身的BUG引入自己的应用。这也是笔者不推荐开发者自己实现框架的原因。虽然Struts2号称是一个全新的框架,但这仅仅是相对Struts1而言。Struts2与Struts1相比,确实有很多革命性的改进,但它并不是新发布的新框架,而是在另一个赫赫有名的框架:WebWork基础上发展起来的。从某种程度上来讲,Strut2没有继承Struts1的血统,而是继承了WebWork的血统。或者说,WebWork衍生出了Struts2,而不是Struts1衍生了Struts2。因为Struts2是WebWork的升级,而不是一个全新的框架,因此稳定性、性能等各方面都有很好的保证;而且吸收了Struts1和WebWork两者的优势,因此,是一个非常值得期待的框架。1.1MVC思想概述今天,我们见到的绝大部分应用,都是基于B/S(浏览器/服务器)架构的,其中的服务器就是Web服务器。可见,Web应用是目前广泛使用的应用模式,而Struts2是一个具有很好的实用价值的WebMVC框架。介绍StrutsMVC框架之前,我们首先介绍Web应用的发展历史和MVC思想。1.1.1Web技术的发展随着Internet技术的广泛使用,Web技术已经广泛应用于Internet上,但早期的Web应用全部是静态的HTML页面,用于将一些文本信息呈现给浏览者,但这些信息是固定写在HTML页面里的,该页面不具备与用户交互的能力,没有动态显示的功能。很自然地,人们希望Web应用里应该包含一些能动态执行的页面,昀早的CGI(通用网关接口)技术满足了该要求,CGI技术使得Web应用可以与客户端浏览器交互,不再需要使用静态的HTML页面。CGI技术可以从数据库读取信息,将这些信息呈现给用户;还可以获取用户的请求参数,并将这些参数保存到数据库里。CGI技术开启了动态Web应用的时代,给了这种技术无限的可能性。但CGI技术存在很多缺点,其中昀大的缺点就是开发动态Web应用难度非常大,而且在性能等各方面也存在限制。到1997年时,随着Java语言的广泛使用,Servlet技术迅速成为动态Web应用的主要开发技术。相比传统的CGI应用而言,Servlet具有大量的优势:—Servlet是基于Java语言创建的,而Java语言则内建了多线程支持,这一点大大提高了动态Web应用的性能。—Servlet应用可以充分利用Java语言的优势,例如JDBC(JavaDataBaseConnection)等。同时,Java语言提供了丰富的类库,这些都简化了Servlet的开发。—除此之外,Servlet运行在Web服务器中,由Web服务器去负责管理Servlet的实例化,并对客户端提供多线程、网络通信等功能,这都保证Servlet有更好的稳定性和性能。Servlet在Web应用中被映射成一个URL(统一资源定位),该URL可以被客户端浏览器请求,当用户向指定URL对应的Servlet发送请求时,该请求被Web服务器接收到,该Web服务器负责处理多线程、网络通信等功能,而Servlet的内容则决定了服务器对客户端的响应内容。图1.1显示了Servlet的响应流程。正如图1.1所显示的,浏览器向Web服务器内指定的Servlet发送请求,Web服务器根据Servlet生成对客户端的响应。实际上,这是后来所有的动态Web编程技术所使用的模型,这种模型都需要一个动态的程序,或者一个动态页面,当客户端向该动态程序或动态页面发送请求时,Web服务器根据该动态程序来生成对客户端的响应。图1.1Servlet的响应流程到了1998年,微软发布了ASP2.0。它是WindowsNT4OptionPack的一部分,作为IIS4.0的外接式附件。它与ASP1.0的主要区别在于它的外部组件是可以初始化的,这样,在ASP程序内部的所有组件都有了独立的内存空间,并可以进行事务处理。标志着ASP技术开始真正作为动态Web编程技术。当ASP技术在世界上广泛流行时,人们很快感受到这种简单的技术的魅力:ASP使用VBScript作为脚本语言,它的语法简单、开发效率非常高。而且,世界上已经有了非常多的VB程序员,这些VB程序员可以很轻易地过渡成ASP程序员——因此,ASP技术马上成为应用昀广泛的动态Web开发技术。随后,由Sun带领的Java阵营,立即发布了JSP标准,从某种程度上来看,JSP是Java阵营为了对抗ASP推出的一种动态Web编程技术。ASP和JSP从名称上如此相似,但它们的运行机制存在一些差别,这主要是因为VBScript是一种脚本语言,无需编译,而JSP使用Java作为脚本语句——但Java从来就不是解释型的脚本语言,因此JSP页面并不能立即执行。因此,JSP必须编译成Servlet,这就是说:JSP的实质还是Servlet。不过,书写JSP比书写Servlet简单得多。JSP的运行机理如图1.2所示。图1.2JSP的运行机理对比图1.1和图1.2,发现不论是Servlet动态Web技术,还是JSP动态Web技术,它们的实质完全一样。可以这样理解:JSP是一种更简单的Servlet技术,这也是JSP技术出现的意义——作为一个和ASP对抗的技术,简单就是JSP的昀大优势。随着实际Web应用的使用越来越广泛,Web应用的规模也越来越大,开发人员发现动态Web应用的维护成本越来越大,即使只需要修改该页面的一个简单按钮文本,或者一段静态的文本内容,也不得不打开混杂的动态脚本的页面源文件进行修改——这是一种很大的风险,完全有可能引入新的错误。这个时候,人们意识到:使用单纯的ASP,或者JSP页面充当过多角色是相当失败的选择,这对于后期的维护相当不利。慢慢地开发人员开始在Web开发中使用MVC模式。随后就是Java阵营发布了一套完整的企业开发规范:J2EE(现在已经更名为JavaEE),紧跟着微软也发布了ASP.NET技术,它们都采用一种优秀的分层思想,力图解决Web应用维护困难的问题。动态Web编程技术大致有如图1.3所示的路线。1.1.2Model1和Model2对于Java阵营的动态Web编程技术而言,则经历了所谓的Model1和Model2时代。图1.3动态Web编程技术的发展历史所谓Model1就是JSP大行其道的时代,在Model1模式下,整个Web应用几乎全部由JSP页面组成,JSP页面接收处理客户端请求,对请求处理后直接做出响应。用少量的JavaBean来处理数据库连接、数据库访问等操作。图1.4显示了Model1的程序流程。Model1模式的实现比较简单,适用于快速开发小规模项目。但从工程化的角度看,它的局限性非常明显:JSP页面身兼View和Controller两种角色,将控制逻辑和表现逻辑混杂在一起,从而导致代码的重用性非常低,增加了应用的扩展性和维护的难度。早期有大量ASP和JSP技术开发出来的Web应用,这些Web应用都采用了Model1架构。Model2已经是基于MVC架构的设计模式。在Model2架构中,Servlet作为前端控制器,负责接收客户端发送的请求,在Servlet中只包含控制逻辑和简单的前端处理;然后,调用后端JavaBean来完成实际的逻辑处理;昀后,转发到相应的JSP页面处理显示逻辑。其具体的实现方式如图1.5所示。图1.4Model1的程序流程图1.5显示了Model2的程序流程。图1.5Model2的程序流程正如图1.5中看到的,Model2下JSP不再承担控制器的责任,它仅仅是表现层角色,仅仅用于将结果呈现给用户,JSP页面的请求与Servlet(控制器)交互,而Servlet负责与后台的JavaBean通信。在Model2模式下,模型(Model)由JavaBean充当,视图(View)由JSP页面充当,而控制器(Controller)则由Servlet充当。由于引入了MVC模式,使Model2具有组件化的特点,更适用于大规模应用的开发,但也增加了应用开发的复杂程度。原本需要一个简单的JSP页面就能实现的应用,在Model2中被分解成多个协同工作的部分,需花更多时间才能真正掌握其设计和实现过程。Model2已经是MVC设计思想下的架构,下面简要介绍MVC设计思想的优势。注意对于非常小型的Web站点,如果后期的更新、维护工作不是特别大,可以使用Model1的模式来开发应用,而不是使用Model2的模式。虽然Model2提供了更好的可扩展性及可维护性,但增加了前期开发成本。从某种程度上讲,Model2为了降低系统后期维护的复杂度,却导致前期开发的更高复杂度。1.1.3MVC思想及其优势MVC并不是Java语言所特有的设计思想,也并不是Web应用所特有的思想,它是所有面向对象程序设计语言都应该遵守的规范。MVC思想将一个应用分成三个基本部分:Model(模型)、View(视图)和Controller(控制器),这三个部分以昀少的耦合协同工作,从而提高应用的可扩展性及可维护性。起初,MVC模式是针对相同的数据需要不同显示的应用而设计的,其整体的效果如图1.6所示。图1.6MVC结构在经典的MVC模式中,事件由控制器处理,控制器根据事件的类型改变模型或视图,反之亦然。具体地说,每个模型对应一系列的视图列表,这种对应关系通常采用注册来完成,即:把多个视图注册到同一个模型,当模型发生改变时,模型向所有注册过的视图发送通知,接下来,视图从对应的模型中获得信息,然后完成视图显示的更新。从设计模式的角度来看,MVC思想非常类似于一个观察者模式,但与观察者模式存在少许差别:观察者模式下观察者和被观察者可以是两个互相对等的对象,但对于MVC思想而言,被观察者往往只是单纯的数据体,而观察者则是单纯的视图页面。概括起来,MVC有如下特点。—多个视图可以对应一个模型。按MVC设计模式,一个模型对应多个视图,可以减少代码的复制及代码的维护量,一旦模型发生改变,也易于维护。—模型返回的数据与显示逻辑分离。模型数据可以应用任何的显示技术,例如,使用JSP页面、Velocity模板或者直接产生Excel文档等。—应用被分隔为三层,降低了各层之间的耦合,提供了应用的可扩展性。—控制层的概念也很有效,由于它把不同的模型和不同的视图组合在一起,完成不同的请求。因此,控制层可以说是包含了用户请求权限的概念。—MVC更符合软件工程化管理的精神。不同的层各司其职,每一层的组件具有相同的特征,有利于通过工程化和工具化产生管理程序代码。相对于早期的MVC思想,Web模式下的MVC思想则又存在一些变化,因为对于一个应用程序而言,我们可以将视图注册给模型,当模型数据发生改变时,即时通知视图页面发生改变;而对于Web应用而言,即使将多个JSP页面注册给一个模型,当模型发生变化时,模型无法主动发送消息给JSP页面(因为Web应用都是基于请求/响应模式的),只有当用户请求浏览该页面时
本文标题:struts2-指南
链接地址:https://www.777doc.com/doc-4524555 .html