现在还用struts框架吗（在Struts应用的视图中包含哪些组件）

本文目录

• 在Struts应用的视图中包含哪些组件
• 如何查看网站是否采用了struts2框架
• 进行Struts应用程序单元测试开发
• 怎么看自己项目用的什么框架
• Struts优缺点剖析 开源是把双刃剑

在Struts应用的视图中包含哪些组件

　　在Struts应用的视图中包含JSP，客户化标签两个组件。
　　Struts是一种基于MVC经典设计模式的开放源代码的应用框架，也是目前Web开发中比较成熟的一种框架。通过把Servlet、JSP、JavaBean、自定义标签和信息资源整合到一个统一的框架中，为Web开发提供了具有高可配置性的MVC开发模式。
　　
　　Struts体系结构实现了MVC设计模式的概念，它将Model、View和Controller分别映射到Web应用中的组件。Model由代表系统状态和商业逻辑Action来构建，View是由JSP和struts提供的自定义标签来实现，Controller负责控制流程，由ActionServlet和ActionMapping来完成。

如何查看网站是否采用了struts2框架

你可以看网站链接url里面的内容，如果是XXX.action结尾或直接XXX？参数1=XXX，应该就是stuts2。

Struts是Apache软件基金会赞助的一个开源项目。它最初是Jakarta项目中的一个子项目，并在2004年3月成为ASF的顶级项目。它通过采用Java Servlet/JSP技术，实现了基于Java EE Web应用的Model-View-Controller设计模式的应用框架，是MVC经典设计模式中的一个经典产品。

Struts2引入了几个新的框架特性：从逻辑中分离出横切关注点的拦截器、减少或者消除配置文件、贯穿整个框架的强大表达式语言、支持可变更和可重用的基于MVC模式的标签API，
Struts2充分利用了从其它MVC框架学到的经验和教训，使得 Struts2框架更加清晰灵活。

Struts 2提供了对MVC的一个清晰的实现，这一实现包含了很多参与对所以请求进行处理的关键组件，如：拦截器、OGNL表达式语言、堆栈。

进行Struts应用程序单元测试开发

　　 一 引言

　　测试驱动开发在减少开发努力的同时也改进了软件的开发质量 单元测试 作为一整套测试策略的基础 必须是全面的 且要求易于建立和执行迅速 然而 对执行环境和被测试类外部代码的依赖性使我们实现这些目标变得更为复杂 例如 把应用程序发布到容器将显著地延长代码和测试的周期 而对其它类的依赖性通常也会导致测试的建立更加复杂和测试运行速度更为缓慢

　　集成两个流行的测试框架（StrutsTestCase和EasyMock）来单元测试Struts应用程序将会更为容易地建立测试并加快测试速度 然而 这两个框架之间尚存在一些 隔阂 从而很难把它们理想地集成到一起 在本文中 我将通过分析两种方案（一个面向对象的方案和一个面向方面的方案）来探讨这个问题 同时 我还将展示面向方面编程(AOP)是如何通过简化一些看起来很困难的问题的解决方案而进一步补充面向对象编程(OOP)的

　　 二 集成需要

　　一个典型的Struts应用程序既能够展示也其所使用的执行环境也会体现出类之间的依赖性问题 这是因为Struts行为（Action）是在一个servlet容器内执行的 并且典型情况下会调用其它的类来处理请求 模拟对象测试方法有助于消除其中不必要的依赖性 借助于继承自基本JUnit测试集的MockStrutsTestCase类 StrutsTestCase测试框架提供了对servlet容器的一种模拟实现 这显然方便了容器外测试 因而也相应地加快了单元测试周期 另一方面 另一个测试框架—EasyMock—进一步便利了对协作类的动态模拟（Mock） 这个框架中所提供的模拟能够用更简单的实现来代替真正的类 并且添加了校验逻辑以支持单元测试

　　非常清楚 把这两个框架结合在一起是非常有益的—Struts应用程序便可以在非常真实的隔离环境下进行测试 理想情况下 你需要使用下列步骤来实现这样的一个单元测试

　　 建立MockStrutsTestCase以便模拟servlet容器

　　 借助于EasyMock来模拟行为所依赖的类

　　 设置模拟的期望值

　　 把模拟注入到当前测试的行为中

　　 继续进行测试和校验

　　注意 上面步骤 中所执行的依赖性注入使被测试的Struts行为远离了其真实的协作者而与一个模拟的行为进行交互 为了把通过EasyMock生成的模拟注入到行为中 你需要从测试类内部存取这些行为相应的实例 遗憾的是 这里出现了一种障碍 因为我们无法轻易地从MockStrutsTestCase中实现这样的存取

　　 三 OOP方案

　　那么 你该如何从MockStrutsTestCase中存取行为实例呢？首先 让我们来分析一下MockStrutsTestCase和Struts的控制器组件之间的关系

　　图 中展示的关键关系有可能潜在地导致一种解决上面问题的方案

　　图 此处展示的关系能够建立一种OOP方案

　　 MockStrutsTestCase中提供了一个public类型的getter方法用于检索ActionServlet

　　 ActionServlet有一个protected类型的getter方法用于实现RequestProcessor

　　 RequestProcessor把行为实例存储为一个protected类型的成员

　　你是否可以子类化ActionServlet和RequestProcessor从而使MockStrutsTestCase能够存取行为呢？相应的结果调用链看上去应该如下所示

　　注意 在你分析完把MockStrutsTestCase链接到Struts行为的调用序列图之后 你就会发现此方法是行不通的

　　图 展示了存在于MockStrutsTestCase和Struts组件之间的关键 *** 互

　　图 存在于MockStrutsTestCase和Struts组件之间的交互

　　图 展示的问题涉及到Struts行为创建的时序问题 到行为内部的模拟注入必须在调用MockStrutsTestCase actionPerform()之前发生 然而 此时这些行为还不可用 因为只有在调用actionPerform()后 Requ

　　estProcessor才能够创建这些行为实例

　　既然你不能很容易地把行为实例传播到MockStrutsTestCase中 那么 为什么不子类化RequestProcessor并重载processActionCreate()方法呢？在这个重载方法中 你可以存取所有的行为实例 这样以来 创建 配置和设置对相应行为实例的一个模拟一下子变得非常直接 因为应该在执行完actionPerform()之后调用MockControl verify()方法 所以 你还需要重载processActionPerform()以进行此校验调用

　　这种方案对于测试正规的Struts应用程序是不太适合的 因为即使所有的行为仅与单个模拟进行交互 测试一个行为也有可能要求多个测试方法—每个方法都具有不同的模拟期望 为此 我们建议的方案是 创建不同的RequestProcessor子类 相应于每个子类设置不同的模拟期望 另外 还需要多个Struts配置文件来指定不同的RequestProcessor子类 最终 管理大量的测试将成为一件令人头疼的事情

　　 四 AOP方案

　　因此 我们非常希望 在执行某行为之前能够通过某种方式实现在MockStrutsTestCase中使用该行为的实例 如果你熟悉AOP 那么 你会立即意识到它所提供的简单方案即能直接满足这一要求 注意 这里的关键是定义一个切点 由它负责捕获行为执行连接点 然后通过一个before advice把模拟注入到相应的行为中

　　在此 我选择使用AspectJ框架来实现这一方案 当然 其它的例如Spring AOP这样的AOP实现也应该能够良好工作 不过 Spring AOP还需要一个额外的步骤—通过Spring框架中的DelegatingActionProxy类把对Struts行为的管理委托给Spring

　　图 展示了基于AOP方案的单元测试示例静态模型

　　图 基于AOP方案的单元测试示例静态模型

　　SimpleAction是一个Struts行为的子类 同时与ActionService进行协作 其中 SimpleActionTest派生于MockStrutsTestCase 用来测试SimpleAction

　　SimpleActionTest使用EasyMock创建和建立一个模拟ActionService SimpleActionTest还实现StrutsActionPreExecuteListener接口以便在即将运行        SimpleAction的execute方法时接收通知 作为通知的一部分 SimpleActionTest接收SimpleAction实例以便注入ActionService模拟 由方面类StrutsActionPreExecuteNotifier负责通知任何实现监听器接口的测试类 并且使相应的行为实例可用

　　下面的步骤描述了实现StrutsActionPreExecuteNotifier的过程

　　◆首先 由一个切点选择相应的测试方法执行连接点 另一方面 这个测试方法驻留于负责监听该行为的预执行事件的测试类中 另外 这个切点还会暴露当前执行的测试类对象 pointcut mockStrutsTest(StrutsActionPreExecuteListener actionTest):

　　◆然后 由第二个切点负责捕获上面的行为执行连接点 通过结合第一个切点 匹配范围被限制到该行为相应的测试方法的调用流程的内部 这种进一步缩小的范围对行为执行（并非通过测试方法激活）起到过滤作用 最终 方面根本不会影响到最后生成的代码 该行为及其相应的测试类实例都是经由切点参数加以暴露的 pointcut strutsActionExecute(Action action StrutsActionPreExecuteListener actionTest):

　　◆最后 由一个与前一个切点相关联的before advice负责通知测试类（它们担任行为事件的监听器）并且传递相应于模拟注入的行为实例

　　图 展示了这些类之间的动态交互情形

　　图 类之间的动态交互

　　注意 图中从行为到方面的虚线描述了对行为执行连接点的捕获情况 此时序图与第一个时序图比较 其重要区别正在于行为执行之前发生的三个步骤

　　 一个切点捕获行为执行连接点（由从SimpleAction指向StrutsActionPreExecuteNotifier的虚线箭头指出）

　　 方面的before advice负责通知测试类并且把相应的行为实例传递给它

　　 测试类把模拟对象注入到即将要开始执行的行为实例中

　　现在 你可以基于前面概括的五个步骤继续编写行为测试 下面的代码展示了相应于SimpleActionTest的部分代码 步骤已在注释中标出

　　使用MockStrutsTestCase和EasyMock进行行为测试的部分代码

　　在行动及其依赖的服务之间存在四种可能的复合关系

　　每个行为依赖于一个服务

　　每个行为依赖于多个服务  

　　多个行为依赖于一个服务  

　　多个行为依赖于多个服务  

　　我在此展示的方案能够比较灵活而且相对容易地支持上面所有这四种情形 因为模拟创建 期望值建立以及模拟注入都能够在单个的测试类内实现

　　你能够不借助于监听器接口就可以在StrutsActionPreExecuteNotifier内部模拟注入吗？这看起来似乎使得测试类实现更简单一些 然而 实践证明 类似早些时候讨论的OOP方案 编写多个方面以创建不同的模拟对象并建立相应的不同的模拟期望是非常必要的 另外 在单个测试类内本地化模拟的创建与安装（借助于监听技术 这是可能的）将变得更为方便

　　 五 总结

　　对于我们在本文中所讨论的集成问题 有人可能会创造出一套相当不错的OOP方案 然而 构造这种方案很可能需要对Struts和StrutsTestCase有深入的理解才行 并且要付出相当的努力 影响本文中所讨论的两个测试框架（StrutsTestCase和EasyMock）紧密集成的主要障碍在于 在Struts行为实例执行之前很难实现对它的访问 在认识了导致这种障碍的基本原因之后 AOP方案自然地出现在我们面前 不必再强求于基于传统型OOP的那种更复杂的方案 AOP允许我们把我们的方案更为紧密地映射到问题空间

怎么看自己项目用的什么框架

1、首先使用开发工具打开以前练手的项目，如下图所示。

2、展开某一个项目目录，查看该项目中的配置文件或类包。如果项目文件中里面仅有applicationContext.xml文件，则代表该项目用了spring框架，如下图所示。

3、打开的项目目录中，如果类包中有action包，配置文件中仅有struts.xml文件，这样的项目一般用了struts2框架。

4、如果项目目录中，可以找到struts.xml、applicationContext.xml，在其他Java类包中还可以找到XX.hbm.xml。这样的项目一般使用SSH三大框架进行整合开发的。

5、如果项目目录中没有struts.xml、applicationContext.xml以及xx.hbm.xml等配置文件，项目类包中有使用servlet的类。这样的Web项目是没有使用任何框架的。

6、如果项目目录配置中有spring.xml、spring-mvc.xml和spring-mybatis.xml等配置文件，通常这样的项目是使用SSM进行整合的项目。

Struts优缺点剖析 开源是把双刃剑

　　Struts优缺点跟Tomcat Turbine等诸多Apache项目一样 是开源软件 这是它的一大优点 使开发者能更深入的了解其内部实现机制

　　Struts开放源码框架的创建是为了使开发者在构建基于Java Servlet和JavaServer Pages（JSP）技术的Web应用时更加容易 Struts框架为开放者提供了一个统一的标准框架 通过使用Struts作为基础 开发者能够更专注于应用程序的商业逻辑 Struts框架本身是使用Java Servlet和JavaServer Pages技术的一种Model View Controller（MVC）实现 具体来讲

　　 Struts优点有

　　 实现MVC模式 结构清晰 使开发者只关注业务逻辑的实现

　　 有丰富的tag可以用 Struts的标记库(Taglib) 如能灵活动用 则能大大提高开发效率 另外 就目前国内的JSP开发者而言 除了使用JSP自带的常用标记外 很少开发自己的标记 或许Struts是一个很好的起点

　　 页面导航 页面导航将是今后的一个发展方向 事实上 这样做 使系统的脉络更加清晰 通过一个配置文件 即可把握整个系统各部分之间的联系 这对于后期的维护有着莫大的好处 尤其是当另一批开发者接手这个项目时 这种优势体现得更加明显

　　 提供Exception处理机制

　　 数据库链接池管理

　　 支持I N

　　 Struts缺点

　　一 转到展示层时 需要配置forward 每一次转到展示层 相信大多数都是直接转到jsp 而涉及到转向 需要配置forward 如果有十个展示层的jsp 需要配置十次struts 而且还不包括有时候目录 文件变更 需要重新修改forward 注意 每次修改配置之后 要求重新部署整个项目 而tomcate这样的服务器 还必须重新启动服务器 如果业务变更复杂频繁的系统 这样的操作简单不可想象 现在就是这样 几十上百个人同时在线使用我们的系统 大家可以想象一下 我的烦恼有多大

　　二 Struts 的Action必需是thread－safe方式 它仅仅允许一个实例去处理所有的请求 所以action用到的所有的资源都必需统一同步 这个就引起了线程安全的问题

　　三 测试不方便 Struts的每个Action都同Web层耦合在一起 这样它的测试依赖于Web容器 单元测试也很难实现 不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试

　　四 类型的转换 Struts的FormBean把所有的数据都作为String类型 它可以使用工具Commons Beanutils进行类型转化 但它的转化都是在Class级别 而且转化的类型是不可配置的 类型转化时的错误信息返回给用户也是非常困难的

　　五 对Servlet的依赖性过强 Struts处理Action时必需要依赖ServletRequest 和ServletResponse 所有它摆脱不了Servlet容器

　　六 前端表达式语言方面 Struts集成了JSTL 所以它主要使用JSTL的表达式语言来获取数据 可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱

　　七 对Action执行的控制困难 Struts创建一个Action 如果想控制它的执行顺序将会非常困难 甚至你要重新去写Servlet来实现你的这个功能需求

　　八 对Action 执行前和后的处理 Struts处理Action的时候是基于class的hierarchies 很难在action处理前和后进行操作

　　九 对事件支持不够 在struts中 实际是一个表单Form对应一个Action类(或DispatchAction) 换一句话说 在Struts中实际是一个表单只能对应一个事件 struts这种事件方式称为application event application event和ponent event相比是一种粗粒度的事件 Struts重要的表单对象ActionForm是一种对象 它代表了一种应用 这个对象中至少包含几个字段 这些字段是Jsp页面表单中的input字段 因为一个表单对应一个事件 所以 当我们需要将事件粒度细化到表单中这些字段时 也就是说 一个字段对应一个事件时 单纯使用Struts就不太可能 当然通过结合JavaScript也是可以转弯实现的