Struts 原理

 Struts作为一个开放原代码的应用框架在JSP Web应用开发中应用得非常广泛。那么，究竟什么是Struts呢？ 

要回答这个问题还得从JSP Web应用的两种基本的结构模式:Model 1和Model 2说起

Model 1结构如图1所示： 


图1 

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

为了克服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的一部分，换句话说，它不应该包含过多的业务逻辑，而应该只是简单地收集业务方法所需要的数据并传递给业务对象。实际上，它的主要职责是：

校验前提条件或者声明

调用需要的业务逻辑方法

检测或处理其他错误

路由控制到相关视图 

上面这样简单的描述，初学者可能会感到有些难以接受，下面举个比较具体的例子来进一步帮助我们理解。如：假设，我们做的是个电子商务程序，现在程序要完成的操作任务是提交定单并返回定单号给客户，这就是关于做什么的问题，应该由Action类完成，但具体怎么获得数据库连接，插入定单数据到数据库表中，又怎么从数据库表中取得这个定单号（一般是自增数据列的数据），这一系列复杂的问题，这都是解决怎么做的问题，则应该由一个（假设名为orderBo）业务对象即Model来完成。orderBo可能用一个返回整型值的名为submitOrder的方法来做这件事，Action则是先校验定单数据是否正确，以免常说的垃圾进垃圾出；如果正确则简单地调用orderBo的submitOrder方法来得到定单号；它还要处理在调用过程中可能出现任何错误；最后根据不同的情况返回不同的结果给客户。