Struts2的学习笔记（3）

       好久没发表了，不表明我没在学习struts2啊，对吧？好，下面仍是把个人一些笔记供出来给你们参考指正吧？ 

1、Struts2应用的分层体系架构：

    

 

2、Struts2的模型驱动（Model Driven），以前所学的称做属性驱动（PropertyDriven）。它们在使用方式上差很少的。

 

3、属性驱动与模型驱动的比较

   1）属性驱动灵活，准确；模型驱动不灵活，由于不少时候，页面所提交过来的参数并不属于模型中的属性，也就是说页面所提交过来的参数与模型中的属性并不一致，这是很常见的状况。

   2）模型驱动更加符合面向对象的编程风格，使得咱们得到的是对象而不是一个个离散的值。

  小结：推荐使用属性驱动编写Action。

 

4、服务器端代码的单元测试有两种模式：

       1) 容器内测试（Jetty）

2）Mock测试（模拟测试：继承httpServletRequest、httpSession、HttpServletResponse等Servlet API）有Jmock ,easyMock测试框架，是对于Web测试的，即服务器端JAVA代码。

 

5、Preparable接口的做用是让Action完成一些初始化工做，这些初始化工做是放在Preparable接口的prepare方法中完成的，该方法会在execute方法执行以前获得调用。

 

6、采起请求转发的方式完成表单内容的添加会形成内容的重复插入。

   

7、采起重定向的方式添加数据不会致使数据的重复插入。

                                                

 

8、防止表单重复提交的两种方式.

   1）经过重定向

   2）经过Session Token（Session 令牌）：当客户端请求页面时，服务器会经过token标签生成一个随机数，而且将该随机数防置到session当中，而后将该随机数发向客户端；若是客户第一次提交，那么会将该随机数发往服务器端，服务器会接收到该随机数而且与session中所保存的随机数进行比较，这时二者的值是相同的，服务器认为是第一次提交，而且将更新服务器端的这个随机数值；若是此时再次重复提交，那么客户端发向服务器端的随机数仍是以前的那个，而服务器端的随机数则已经发生了变化，二者不一样，服务器就认为这是重复提交，进而转向invalid.token所指向的结果页面。

 

9、token拦截器用于保证表单只被提交一次。例如：TokenAction中有一个NAMES属性，用来存储提交过的全部的数据。重复提交数据时，若是能提交进来，NAMES将会积累重复的数据，以此来判断数据是否被重复提交。注意，NAME属性在自动生成隔get函数时是小写的，要动手改回大写，否则会出错。

 

10、拦截器（interceptor）：拦截器是struts2的核心，struts2的众多功能都是经过拦截器来实现的。

 

十一、一旦定义了本身的拦截器，将其配置到action上后，咱们须要在action的最后加上默认的拦截器栈：defaultStack。

 

12、拦截器的配置

1）编写实现interceptor接口的类

2）在struts.xml文件中定义拦截器

3）在action中使用拦截器