最近在網上看到一篇N. Alex Rupp寫的“Beyond MVC: A New Look at the Servlet InfrastrUCture”文章，意思大致是說MVC被Struts等框架錯誤地應用到了Servlet架構中。我想只有對Struts有足夠的了解再加上在MVC方面有足夠深的功力，才敢發此言論，不是經常聽人說：最熟悉自己的人是你的敵人。本人功力尚淺，沒有引領風潮的能力，而且生活還得繼續，只能先來熟悉熟悉Struts。

申明： 強烈建議在閱讀本文之前先閱讀一下N. Alex Rupp老兄的文章，假如你贊同他的看法，可能你會覺得研究Struts就沒什么意義了。

說明：本文所講的Struts知識基于Struts 1.1版本，除非非凡說明，本文中的Struts都特指Struts 1.1這個版本。

精細之處一：“利用Token解決重復提交”背后的前提

我們知道，可以利用同步令牌（Token）機制來解決Web應用中重復提交的問題，Struts也給出了一個參考實現。服務器端在處理到達的請求之前，會將請求中包含的令牌值與保存在當前用戶會話中的令牌值進行比較，看是否匹配。在處理完該請求后，且在答復發送給客戶端之前，將會產生一個新的令牌，該令牌除傳給客戶端以外，也會將用戶會話中保存的舊的令牌進行替換。這樣假如用戶回退到剛才的提交頁面并再次提交的話，客戶端傳過來的令牌就和服務器端的令牌不一致，從而有效地防止了重復提交的發生。對應于這段描述，你可能會在你的Action子類中有這么一段代碼：

if (isTokenValid(request, true)) {	// your code herereturn mapping.findForward("success");} else {saveToken(request);return mapping.findForward("submitagain");}

其中isTokenValid()和saveToken()都是org.apache.struts.action.Action類中的方法，而具體的Token處理邏輯都在org.apache.struts.util.TokenPRocessor類中。Struts中是根據用戶會話ID和當前系統時間來生成一個唯一（對于每個會話）令牌的，具體實現可以參考TokenProcessor類中的generateToken()方法。

不知道大家有沒有注重到這樣一個問題，因為Struts是將Token保存在session的一個屬性中，也就是說對于每個會話服務器端只保存而且只能保存一個最新Token值。對于這一點，我的同事就提出了疑問：那假如我在同一個會話中打開兩個頁面，那么后提交的那個頁面肯定不能提交成功了。他還給出了一個實際的例子：比如現在需要把兩個客戶A和B的地址都改為某個值，那用戶就可能同時打開兩個頁面，修改A，修改B，提交A，提交B，按照Struts中的處理邏輯，B的修改提交就肯定不能成功，但是這個提交操作對于用戶來說并不存在操作不正確的地方。

在這里，可能有人要問：怎么可能在同一個會話中打開兩個頁面呢？重新打開一個IE瀏覽器不是重新開始了一個會話嗎？不錯，這種情況下是兩個會話，不存在任何問題。但是，你還可以通過菜單“文件”－“新建”－“窗口”（或者快捷鍵Ctrl+N）來復制當前窗口，這個時候你會發現該頁面與原有頁面同處在一個會話當中。其實，能夠發現這個問題得歸功于我的那位同事對IE習慣性的操作方法。

這下我的那位同事不滿足啦，他于是開始動手修改Struts中的實現方式，讓每個頁面（至少某類頁面）在服務器端都保存有一個唯一的Token值。這樣，前面所講的客戶A，B同時修改的限制就不存在了。但是不久，我的那位同事就開始意識到他正在走向一條危險的道路。首先，假如每個頁面都在服務器端保存一個Token值，則服務器端保存的數據量將越來越大。而且，假如考慮這種同一個會話中打開多個頁面的情況的話，就似乎打開了潘多拉魔盒，將會給自己帶來無窮無盡的麻煩。比如，首先打開頁面P1，然后利用Ctrl+N得到頁面P2，P1提交，P2提交，目前為止一切正常。但是假如此時，在P1，P2中點擊“后退”按鈕，然后再提交P1， P2呢，情況會是怎樣？假如在P2中提交完后執行其它操作，而在P1中回退后提交，情況又是怎么樣呢？假如有P1，P2，P3，那情況又是如何呢？太復雜啦！我想你也會和我們有同感，你需要考慮許多種可能的組合，而且有的時候結果并不是你想象中的那樣簡單。

此路不通，還得回來看看Struts。其實經過以上一番折騰，我們可以發現在Struts中的Token機制背后隱藏著這樣一個前提：不答應你（客戶端）在同一會話中打開多個頁面。注重是同一會話，假如打開兩個IE瀏覽器，那已經是兩個會話啦，不受該限制。其實，這個看似不合理的規定卻自有其道理：一是它極大地簡化了Token的實現，二個這種限定也符合大部分人的使用習慣。

精細之處二：頁面流轉控制中的職責分配

我們知道，Struts的執行過程大致如下：首先，控制器接收到客戶端請求，將這些請求映射至相應的Action，并調用Action的execute方法，這中間可能還涉及到ActionForm的創建和填充。Action的execute方法執行完以后，返回一個ActionForward對象，控制器根據該ActionForward對象將請求轉發至下一個Action或jsp。最后，產生視圖響應客戶。在大的層面上，Struts是采用了MVC這種架構，沒什么非凡之處。但從一些小的地方，我們還是可以看出Craig R. McClanahan老兄的一些考慮。我們看到Action與控制器之間傳遞的是ActionForward對象，由于Action的execute方法要求返回一個ActionForward對象，所以你會經常在Action子類中看到如下語句：