Struts原理与实践 - -

第1部分)

一、 什么是Struts

框架（Framework）是可重用的，半完成的应用程序，可以用来产生专门的定制程序。

您只要细心地研究真实的应用程序，就会发现程序大致上由两类性质不同的组件组成，一类与程序要处理的具体事务密切相关，我们不妨把它们叫做业务组件；另一类是应用服务。比如说：一个税务征管系统和一个图书管理系统会在处理它们的业务方面存在很大的差异，这些直接处理业务的组件由于业务性质的不同不大可能在不同的系统中重用，而另一些组件如决定程序流向的控制、输入的校验、错误处理及标签库等这些只与程序相关的组件在不同的系统中可以很好地得到重用。人们自然会想要是把这些在不同应用程序中有共性的一些东西抽取出来，做成一个半成品程序，这样的半成品就是所谓的程序框架，再做一个新的东西时就不必白手起家，而是可以在这个基础上开始搭建。实际上，有些大型软件企业选择自己搭建这样的框架。但大多数中小型软件企业或者其他组织，没有条件自己建立框架。

Struts作为一个开放原代码的应用框架，在最近几年得到了飞速的发展，在JSP Web应用开发中应用得非常广泛，有的文献上说它已经成为JSP Web应用框架的事实上的标准。那么，究竟什么是Struts呢？

要回答这个问题还得从JSP Web应用的两种基本的结构模式:Model 1和Model 2说起，为了给读者一些实实在在的帮助，并力图让学习曲线变得平坦一些，我想采用实例驱动的方法来逐步深入地回答有关问题，因为，学一门技术的最好方法莫过于在实践中学习、在实践中体会，逐步加深对其精神实质的理解和把握，而不是一上来就引入一大堆新概念让大家觉得无所适从，或者死记硬背一大堆概念而面对一个真正的实际需求束手无策。正如，一个人即使在书本上学成了游泳博士，只要他不下水，我想他也是不大可能真正会游泳的。

Model 1结构如图1所示：



图1

mode1 1是一个以JSP文件为中心的模式，在这种模式中JSP页面不仅负责表现逻辑，也负责控制逻辑。专业书籍上称之为逻辑耦合在页面中，这种处理方式，对一些规模很小的项目如：一个简单的留言簿，也没什么太大的坏处，实际上，人们开始接触一些对自己来说是新的东西的时候，比如，用JSP访问数据库时，往往喜欢别人能提供一个包含这一切的单个JSP页面，因为这样在一个页面上他就可以把握全局，便于理解。但是，用Model 1模式开发大型时，程序流向由一些互相能够感知的页面决定，当页面很多时要清楚地把握其流向将是很复杂的事情，当您修改一页时可能会影响相关的很多页面，大有牵一发而动全身的感觉，使得程序的修改与维护变得异常困难；还有一个问题就是程序逻辑开发与页面设计纠缠在一起，既不便于分工合作也不利于代码的重用，这样的程序其健壮性和可伸缩性都不好。

Grady Booch等人在UML用户指南一书中，强调建模的重要性时，打了一个制作狗窝、私人住宅、和大厦的形象比喻来说明人们处理不同规模的事物时应该采用的合理方法一样，人们对不同规模的应用程序也应该采用不同的模式。

为了克服Model 1的缺陷，人们引入了Model 2，如图2所示：



图2

它引入了"控制器"这个概念，控制器一般由Servlet来担任，客户端的请求不再直接送给一个处理业务逻辑的JSP页面，而是送给这个控制器，再由控制器根据具体的请求调用不同的事务逻辑，并将处理结果返回到合适的页面。因此，这个servlet控制器为应用程序提供了一个进行前-后端处理的中枢。一方面为输入数据的验证、身份认证、日志及实现国际化编程提供了一个合适的切入点；另一方面也提供了将业务逻辑从JSP文件剥离的可能。业务逻辑从JSP页面分离后，JSP文件蜕变成一个单纯完成显示任务的东西，这就是常说的View。而独立出来的事务逻辑变成人们常说的Model,再加上控制器Control本身，就构成了MVC模式。实践证明，MVC模式为大型程序的开发及维护提供了巨大的便利。

其实，MVC开始并不是为Web应用程序提出的模式，传统的MVC要求M将其状态变化通报给V，但由于Web浏览器工作在典型的拉模式而非推模式，很难做到这一点。因此有些人又将用于Web应用的MVC称之为MVC2。正如上面所提到的MVC是一种模式，当然可以有各种不同的具体实现，包括您自己就可以实现一个体现MVC思想的程序框架，Struts就是一种具体实现MVC2的程序框架。它的大致结构如图三所示：



图三

图三基本勾勒出了一个基于Struts的应用程序的结构，从左到右，分别是其表示层（view）、控制层(controller)、和模型层(Model)。其表示层使用Struts标签库构建。来自客户的所有需要通过框架的请求统一由叫ActionServlet的servlet接收（ActionServlet Struts已经为我们写好了，只要您应用没有什么特别的要求，它基本上都能满足您的要求），根据接收的请求参数和Struts配置(struts-config.XML)中ActionMapping，将请求送给合适的Action去处理，解决由谁做的问题，它们共同构成Struts的控制器。Action则是Struts应用中真正干活的组件，开发人员一般都要在这里耗费大量的时间，它解决的是做什么的问题，它通过调用需要的业务组件（模型）来完成应用的业务，业务组件解决的是如何做的问题，并将执行的结果返回一个代表所需的描绘响应的JSP（或Action）的ActionForward对象给ActionServlet以将响应呈现给客户。

过程如图四所示：



图四

这里要特别说明一下的是：就是Action这个类，上面已经说到了它是Struts中真正干活的地方，也是值得我们高度关注的地方。可是，关于它到底是属于控制层还是属于模型层，存在两种不同的意见，一种认为它属于模型层，如：《JSP Web编程指南》；另一些则认为它属于控制层如：《Programming Jakarta Struts》、《Mastering Jakarta Struts》和《Struts Kick Start》等认为它是控制器的一部分，还有其他一些书如《Struts in Action》也建议要避免将业务逻辑放在Action类中，也就是说，图3中Action后的括号中的内容应该从中移出，但实际中确有一些系统将比较简单的且不打算重用的业务逻辑放在Action中，所以在图中还是这样表示。显然，将业务对象从Action分离出来后有利于它的重用，同时也增强了应用程序的健壮性和设计的灵活性。因此，它实际上可以看作是Controller与Model的适配器，如果硬要把它归于那一部分，笔者更倾向于后一种看法，即它是Controller的一部分，换句话说，它不应该包含过多的业务逻辑，而应该只是简单地收集业务方法所需要的数据并传递给业务对象。实际上，它的主要职责是：

标签：