Struts 是基于Model 2之上的，而Model 2是經典的MVC（模型－視圖－控制器）模型的Web應用變體，這個改變主要是由于網絡應用的特性--HTTP協(xié)議的無狀態(tài)性引起的。Model 2的目的和MVC一樣，也是利用控制器來分離模型和視圖，達到一種層間松散耦合的效果，提高系統(tǒng)靈活性、復用性和可維護性。在多數(shù)情況下，你可以將 Model 2與MVC等同起來。
下圖表示一個基于Java技術的典型網絡應用，從中可以看出Model 2中的各個部分是如何對應于Java中各種現(xiàn)有技術的。
在利用Model 2之前，我們是把所有的表示邏輯和業(yè)務邏輯都集中在一起（比如大雜燴似的JSP），有時也稱這種應用模式為Model 1，Model 1的主要缺點就是緊耦合，復用性差以及維護成本高。
既然Struts 1.1是基于Model 2之上，那它的底層機制也就是MVC，下面是Struts 1.1中的MVC實現(xiàn)示意圖：
圖解說明：其中不同顏色代表MVC的不同部分：紅色（控制器）、紫色（模型）和綠色（視圖）
首先，控制器（ActionServlet）進行初始化工作，讀取配置文件（struts- config.xml），為不同的Struts模塊初始化相應的ModuleConfig對象。比如配置文件中的Action映射定義都保存在 ActionConfig集合中。相應地有ControlConfig集合、FormBeanConfig集合、ForwardConfig集合和 MessageResourcesConfig集合等。
提示： 模 塊是在Struts 1.1中新提出的概念，在稍后的內容中我們將詳細介紹，你現(xiàn)在可以簡單地把模塊看作是一個子系統(tǒng)，它們共同組成整個應用，同時又各自獨立。Struts 1.1中所有的處理都是在特定模塊環(huán)境中進行的。模塊的提出主要是為了解決Struts 1.0中單配置文件的問題。
控制器接收HTTP請求，并從ActionConfig中找出對應于該請求的Action子類，如果沒有對應的Action，控制器直接將請求轉發(fā)給JSP或者靜態(tài)頁面。否則控制器將請求分發(fā)至具體Action類進行處理。
在 控制器調用具體Action的execute方法之前，ActionForm對象將利用HTTP請求中的參數(shù)來填充自己（可選步驟，需要在配置文件中指 定）。具體的ActionForm對象應該是ActionForm的子類對象，它其實就是一個JavaBean。此外，還可以在ActionForm類中 調用validate方法來檢查請求參數(shù)的合法性，并且可以返回一個包含所有錯誤信息的ActionErrors對象。如果執(zhí)行成功， ActionForm自動將這些參數(shù)信息以JavaBean（一般稱之為form bean）的方式保存在Servlet Context中，這樣它們就可以被其它Action對象或者JSP調用。
Struts將這些ActionForm的配置信息都放在FormBeanConfig集合中，通過它們Struts能夠知道針對某個客戶請求是否需要創(chuàng)建相應的ActionForm實例。
Action 很簡單，一般只包含一個execute方法，它負責執(zhí)行相應的業(yè)務邏輯，如果需要，它也進行相應的數(shù)據(jù)檢查。執(zhí)行完成之后，返回一個 ActionForward對象，控制器通過該ActionForward對象來進行轉發(fā)工作。我們主張將獲取數(shù)據(jù)和執(zhí)行業(yè)務邏輯的功能放到具體的 JavaBean當中，而Action只負責完成與控制有關的功能。遵循該原則，所以在上圖中我將Action對象歸為控制器部分。
提示： 其 實在Struts 1.1中，ActionMapping的作用完全可以由ActionConfig來替代，只不過由于它是公共API的一部分以及兼容性的問題得以保留。 ActionMapping通過繼承ActionConfig來獲得與其一致的功能，你可以等同地看待它們。同理，其它例如ActionForward與 ForwardConfig的關系也是如此。
下圖給出了客戶端從發(fā)出請求到獲得響應整個過程的圖解說明。
下面我們就來詳細地討論一下其中的每個部分，在這之前，先來了解一下模塊的概念。
我 們知道，在Struts 1.0中，我們只能在web.xml中為ActionServlet指定一個配置文件，這對于我們這些網上的教學例子來說當然沒什么問題，但是在實際的應 用開發(fā)過程中，可能會有些麻煩。因為許多開發(fā)人員都可能同時需要修改配置文件，但是配置文件只能同時被一個人修改，這樣肯定會造成一定程度上的資源爭奪， 勢必會影響開發(fā)效率和引起開發(fā)人員的抱怨。
在Struts 1.1中，為了解決這個并行開發(fā)的問題，提出了兩種解決方案：
- 多個配置文件的支持
- 模塊的支持
支持多個配置文件，是指你能夠為ActionServlet同時指定多個xml配置文件，文件之間以逗號分隔，比如Struts提供的MailReader演示例子中就采用該種方法。
<!-- Action Servlet Configuration -->
|
這種方法可以很好地解決修改沖突的問題，不 同的開發(fā)人員可以在不同的配置文件中設置自己的Action、ActionForm等等（當然不是說每個開發(fā)人員都需要自己的配置文件，可以按照系統(tǒng)的功 能模塊進行劃分）。但是，這里還是存在一個潛在的問題，就是可能不同的配置文件之間會產生沖突，因為在ActionServlet初始化的時候這幾個文件 最終還是需要合并到一起的。比如，在struts-config.xml中配置了一個名為success的<forward>，而在 struts-config-registration.xml中也配置了一個同樣的<forward>，那么執(zhí)行起來就會產生沖突。
為 了徹底解決這種沖突，Struts 1.1中引進了模塊（Module）的概念。一個模塊就是一個獨立的子系統(tǒng)，你可以在其中進行任意所需的配置，同時又不必擔心和其它的配置文件產生沖突。 因為前面我們講過，ActionServlet是將不同的模塊信息保存在不同的ModuleConfig對象中的。要使用模塊的功能，需要進行以下的準備 工作：
1、為每個模塊準備一個配置文件
2、配置web.xml文件，通知控制器
決定采用多個模塊以后，你需要將這些信息告訴控制器，這需要在web.xml文件進行配置。下面是一個典型的多模塊配置：
<init-param>
|
要配置多個模塊，你需要在原有的一個 <init-param>（在Struts 1.1中將其對應的模塊稱為缺省模塊）的基礎之上，增加模塊對應的<init-param>。其中<param-name>表示 為config/XXX的形式，其中XXX為對應的模塊名，<param-value>中還是指定模塊對應的配置文件。上面這個例子說明該應 用有三個模塊，分別是缺省模塊、customer和order，它們分別對應不同的配置文件。
3、準備各個模塊所需的ActionForm、Action和JSP等資源
但 是要注意的是，模塊的出現(xiàn)也同時帶來了一個問題，即如何在不同模塊間進行轉發(fā)？有兩種方法可以實現(xiàn)模塊間的轉發(fā)，一種就是在< forward>（全局或者本地）中定義，另外一種就是利用org.apache.struts.actions.SwitchAction。
下面就是一個全局的例子：
...
|
可以看出，只需要在原有的path屬性前加上模塊名，同時將contextRelative屬性置為true即可。此外，你也可以在<action>中定義一個類似的本地<forward>。
<action-mappings>
|
如果你已經處在其他模塊，需要轉回到缺省模塊，那應該類似下面這樣定義，即模塊名為空。
<forward name="success" contextRelative="true" path="/login.do"/>
|
此外，你也可以使用org.apache.struts.actions.SwitchAction，例如：
...
|
我們首先來了解MVC中的控制器。在Struts 1.1中缺省采用ActionServlet類來充當控制器。當然如果ActionServlet不能滿足你的需求，你也可以通過繼承它來實現(xiàn)自己的類。這可以在/WEB-INF/web.xml中來具體指定。
要 掌握ActionServlet，就必須了解它所扮演的角色。首先，ActionServlet表示MVC結構中的控制器部分，它需要完成控制器所需的前 端控制及轉發(fā)請求等職責。其次，ActionServlet被實現(xiàn)為一個專門處理HTTP請求的Servlet，它同時具有servlet的特點。在 Struts 1.1中它主要完成以下功能：
- 接收客戶端請求
- 根據(jù)客戶端的URI將請求映射到一個相應的Action類
- 從請求中獲取數(shù)據(jù)填充Form Bean（如果需要）
- 調用Action類的execute()方法獲取數(shù)據(jù)或者執(zhí)行業(yè)務邏輯
- 選擇正確的視圖響應客戶
此 外，ActionServlet還負責初始化和清除應用配置信息的任務。ActionServlet的初始化工作在init方法中完成，它可以分為兩個部 分：初始化ActionServlet自身的一些信息以及每個模塊的配置信息。前者主要通過initInternal、initOther和 initServlet三個方法來完成。
我們可以在/WEB-INF/web.xml中指定具體的控制器以及初 始參數(shù)，由于版本的變化以及Struts 1.1中模塊概念的引進，一些初始參數(shù)被廢棄或者移入到/WEB-INF/struts-config.xml中定義。下面列出所有被廢棄的參數(shù)，相應地 在web.xml文件中也不鼓勵再使用。
- application
- bufferSize
- content
- debug
- factory
- formBean
- forward
- locale
- mapping
- maxFileSize
- multipartClass
- nocache
- null
- tempDir
ActionServlet根據(jù)不同的模塊來初始化ModuleConfig類，并在其中以XXXconfig集合的方式保存該模塊的各種配置信息，比如ActionConfig，F(xiàn)ormBeanConfig等。
初 始化工作完成之后，ActionServlet準備接收客戶請求。針對每個請求，方法process(HttpServletRequest request, HttpServletResponse response)將被調用。該方法指定具體的模塊，然后調用該模塊的RequestProcessor的process方法。
protected void process(HttpServletRequest request,
|
RequestProcessor包含了Struts控制器的所有處理邏輯，它調用不同的processXXX方法來完成不同的處理。下表列出其中幾個主要的方法：
| 方法 | 功能 |
| processPath | 獲取客戶端的請求路徑 |
| processMapping | 利用路徑來獲得相應的ActionMapping |
| processActionForm | 初始化ActionForm（如果需要）并存入正確的scope中 |
| processActionCreate | 初始化Action |
| processActionPerform | 調用Action的execute方法 |
| processForwardConfig | 處理Action返回的ActionForward |
|
對于ActionForm你可以從以下幾個方面來理解它：
- ActionForm 表示HTTP窗體中的數(shù)據(jù)，可以將其看作是模型和視圖的中介，它負責保存視圖中的數(shù)據(jù)供模型或者視圖使用。Struts 1.1文檔中把它比作HTTP和Action之間的防火墻，這體現(xiàn)了ActionForm具有的過濾保護的作用，只有通過ActionForm驗證的數(shù)據(jù) 才能夠發(fā)送到Action處理。
- ActionForm是與一個或多個ActionConfig關聯(lián)的JavaBean，在相應的action的execute方法被調用之前，ActionForm會自動利用請求參數(shù)來填充自己（初始化屬性）。
- ActionForm是一個抽象類，你必須通過繼承來實現(xiàn)自己的類。
ActionForm 首先利用屬性的getter和setter方法來實現(xiàn)初始化，初始化完畢后，ActionForm的validate方法被調用，你可以在其中來檢查請求 參數(shù)的正確性和有效性，并且可以將錯誤信息以ActionErrors的形式返回到輸入窗體。否則，ActionForm將被作為參數(shù)傳給action的 execute方法以供使用。
ActionForm bean的生命周期可以設置為session（缺省）和request，當設置為session時，記得在reset方法中將所有的屬性重新設置為初始值。
由 于ActionForm對應于HTTP窗體，所以隨著頁面的增多，你的ActionForm將會急速增加。而且可能同一類型頁面字段將會在不同的 ActionForm中出現(xiàn)，并且在每個ActionForm中都存在相同的驗證代碼。為了解決這個問題，你可以為整個應用實現(xiàn)一個ActionForm 或者至少一個模塊對應于一個ActionForm。
但是，聚合的代價就是復用性很差，而且難維護。針對這個問題，在Struts 1.1中提出了DynaActionForm的概念。
DynaActionForm類
DynaActionForm 的目的就是減少ActionForm的數(shù)目，利用它你不必創(chuàng)建一個個具體的ActionForm類，而是在配置文件中配置出所需的虛擬 ActionForm。例如，在下表中通過指定<form-bean>的type為 "org.apache.struts.action.DynaActionForm"來創(chuàng)建一個動態(tài)的ActionForm--loginForm。
<form-beans>
|
動態(tài)的ActionForm的使用方法跟普 通的ActionForm相同，但是要注意一點。普通的ActionForm對象需要為每個屬性提供getter和setter方法，以上面的例子而言， 我們需要提供getUsername() 和 setUsername()方法取得和設置username屬性，同樣地有一對方法用于取得和設置password屬性和actionClass屬性。
如 果使用DynaActionForm，它將屬性保存在一個HashMap類對象中，同時提供相應的get(name) 和 set(name)方法，其中參數(shù)name是要訪問的屬性名。例如要訪問DynaActionForm中username的值，可以采用類似的代碼：
String username = (String)form.get("username")；
|
由于值存放于一個HashMap對象，所以要記得對get()方法返回的Object對象做強制性類型轉換。正是由于這點區(qū)別，如果你在Action中非常頻繁地使用ActionForm對象，建議還是使用普通的ActionForm對象。
在Struts 1.1中，除了DynaActionForm以外，還提供了表單輸入自動驗證的功能，在包org.apache.struts.validator中提供了許多有用的類，其中最常見的就是DynaValidatorForm類。
DynaValidatorForm類
DynaValidatorForm是DynaActionForm的子類，它能夠提供動態(tài)ActionForm和自動表單輸入驗證的功能。和使用DynaActionForm類似，你必須首先在配置文件中進行配置：
<form-beans>
|
同時要定義驗證的插件：
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
|
其中的validator.xml和validator-rules.xml分別表示驗證定義和驗證規(guī)則的內容（可以合并在一起），比如針對上例中的DynaValidatorForm，我們有如下驗證定義（validator.xml）：
<?xml version="1.0" encoding="ISO-8859-1" ?>
|
從上述定義中，我們可以看到對于字段 username有三項驗證：required, minlength, maxlength，意思是該字段不能為空，而且長度在3和16之間。而validator-rules.xml文件則可以采用Struts提供的缺省文 件。注意在<form-bean>中定義的form是如何與validation.xml中的form關聯(lián)起來的。最后，要啟動自動驗證功 能，還需要將Action配置的validate屬性設置為true。
<action path="/login"
|
此時，Struts將根據(jù)xml配置文件中的定義來檢驗表單輸入，并將不符合要求的錯誤信息輸出到頁面。但是你可能會想：這個功能雖然好，可是什么檢驗都跑到服務器端執(zhí)行，效率方面和用戶易用性方面是不是有些問題？你可能會懷念起那簡單的JavaScript客戶端驗證。
不 用擔心，在Struts 1.1中也支持JavaScript客戶端驗證。如果你選擇了客戶端驗證，當某個表單被提交以后，Struts 1.1啟動客戶端驗證，如果瀏覽器不支持JavaScript驗證，則服務器端驗證被啟動，這種雙重驗證機制能夠最大限度地滿足各種開發(fā)者的需要。 JavaScript驗證代碼也是在validator-rules.xml文件中定義的。要啟動客戶端驗證，你必須在相應的JSP文件中做如下設置：
- 為<html:form>增加onsubmit屬性
- 設置Javascript支持
下表中列出了一JSP文件的示例代碼，紅字部分為Javascript驗證所需代碼。
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
|
其中onsubmit的值為"return validateLoginForm(this);"，它的語法為：
return validate + struts-config.xml中定義的form-bean名稱 + (this);
staticJavascript.jsp的內容為：
<%@ page language="java" %>
|
如果validator-rules.xml中定義的基本驗證功能不能滿足你的需求，你可以自己添加所需的驗證類型。
|
|
我們通過繼承Action類來實現(xiàn)具體的執(zhí)行類。具體Action類的功能一般都在execute（以前是perform方法）方法中完成，其中主要涉及到以下幾個方面：
- 輔助ActionForm進行一些表單數(shù)據(jù)的檢查。
- 執(zhí)行必要的業(yè)務邏輯，比如存取數(shù)據(jù)庫，調用實體bean等。
- 更新服務器端的bean數(shù)據(jù)，后續(xù)對象中可能會用到這些數(shù)據(jù)，比如在JSP中利用bean:write來獲得這些數(shù)據(jù)。
- 根據(jù)處理結果決定程序的去處，并以ActionForward對象的形式返回給ActionServlet。
提示： 由 于在Action和ActionForm中都可以實現(xiàn)驗證方法，那么如何來安排它們之間的分工呢？一般來說，我們秉著MVC分離的原則，也就是視圖級的驗 證工作放在ActionForm來完成，比如輸入不能為空，email格式是否正確，利用ValidatorForm可以很輕松地完成這些工作。而與具體 業(yè)務相關的驗證則放入Action中，這樣就可以獲得最大ActionForm重用性的可能。
前面我們提到過，我們主張將業(yè)務邏輯執(zhí)行分離到單獨的 JavaBean中，而Action只負責錯誤處理和流程控制。而且考慮到重用性的原因，在執(zhí)行業(yè)務邏輯的JavaBean中不要引用任何與Web應用相 關的對象，比如HttpServletRequest，HttpServletResponse等對象，而應該將其轉化為普通的Java對象。關于這一 點，可以參考Petstore中WAF框架的實現(xiàn)思路。
此外，你可能還注意到execute與perform的 一個區(qū)別：execute方法簡單地擲出Exception異常，而perform方法則擲出ServletException和IOException 異常。這不是說Struts 1.1在異常處理功能方面弱化了，而是為了配合Struts 1.1中一個很好的功能--宣稱式異常處理機制。
|
|
和EJB中的宣稱式事務處理概念類似，宣稱式異常處理其實就是可配置的異常處理，你可以在配置文件中指定由誰來處理Action類中擲出的某種異常。你可以按照以下步驟來完成該功能：
- 實現(xiàn)org.apache.struts.action.ExceptionHandler的子類，覆蓋execute方法，在該方法中處理異常并且返回一個ActionForward對象
- 在配置文件中配置異常處理對象，你可以配置一個全局的處理類或者單獨為每個Action配置處理類
下表就定義了一個全局的處理類CustomizedExceptionHandler，它被用來處理所有的異常。
<global-exceptions>
|
其中具體的參數(shù)含義，可以參考ExceptionHandler.java源文件。
|
|
講 完了模型和控制器，接下來我們要涉及的是視圖。視圖的角色主要是由JSP來完成，從JSP的規(guī)范中可以看出，在視圖層可以"折騰"的技術不是很多，主要的 就是自定義標記庫的應用。Struts 1.1在原有的四個標記庫的基礎上新增了兩個標記庫--Tiles和Nested。
其 中Tiles除了替代Template的基本模板功能外，還增加了布局定義、虛擬頁面定義和動態(tài)頁面生成等功能。Tiles強大的模板功能能夠使頁面獲得 最大的重用性和靈活性，此外可以結合Tiles配置文件中的頁面定義和Action的轉發(fā)邏輯，即你可以將一個Action轉發(fā)到一個在Tiles配置文 件中定義的虛擬頁面，從而減少頁面的數(shù)量。比如，下表中的Action定義了一個轉發(fā)路徑，它的終點是tile.userMain，而后者是你在 Tiles配置文件中定義的一個頁面。
<!-- ========== Action Mapping Definitions ============================== -->
|
Tiles配置文件：tiles-defs.xml
<!DOCTYPE tiles-definitions PUBLIC
|
而Nested標記庫的作用是讓以上這些基本標記庫能夠嵌套使用，發(fā)揮更大的作用。
|
|
所 謂的Commons Logging接口，是指將日志功能的使用與日志具體實現(xiàn)分開，通過配置文件來指定具體使用的日志實現(xiàn)。這樣你就可以在Struts 1.1中通過統(tǒng)一的接口來使用日志功能，而不去管具體是利用的哪種日志實現(xiàn)，有點于類似JDBC的功能。Struts 1.1中支持的日志實現(xiàn)包括：Log4J，JDK Logging API， LogKit，NoOpLog和SimpleLog。
你可以按照如下的方式來使用Commons Logging接口（可以參照Struts源文中的許多類實現(xiàn)）：
package com.foo;
|
而開啟日志功能最簡單的辦法就是在WEB-INF/classes目錄下添加以下兩個文件：
commons-logging.properties文件：
# Note: The Tiles framework now uses the commons-logging package to output different information or debug statements.
|
simplelog.properties文件：
# Logging detail level,
|
這里我們采用的日志實現(xiàn)是 SimpleLog，你可以在simplelog.properties文件指定日志明細的級別：trace，debug，info，warn， error和fatal，從trace到fatal錯誤級別越來越高，同時輸出的日志信息也越來越少。而這些級別是和 org.apache.commons.logging.log接口中的方法一一對應的。這些級別是向后包含的，也就是前面的級別包含后面級別的信息。
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
