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中使用攔截器