2.1 Struts 2概述

2.1.1 Struts 1的缺陷

Struts 1框架是一個非常流行的框架，同樣也是現在的MVC主流框架，但是Struts 1框架存在著一些問題。框架的流行和框架中存在的問題是不會有必然的聯系的。就拿MFC來說，MFC存在許多問題，比如代碼過于龐大、格式固定等。但是，一直到現在還是有很多程序仍然使用它來開發。這是為什么呢？是因為大量的開發人員已經習慣了這種開發模式，短時間內無法轉到其他的開發平臺上。不過隨著時間和技術的發展，這種技術的運用會越來越少，最終會被新出現的技術淘汰的。

Struts 1也是因為出現的年代比較早，所以隨著時間的發展，存在的問題也越來越明顯。Struts 1存在的問題大致可分為5類。

（1）代碼與Servlet API耦合度高，難于測試。

Struts 1中的業務邏輯控制器Action與Servlet API耦合度高，難于測試。所謂耦合度，是指模塊之間聯系的緊密程度。耦合度高是指模塊之間的緊密程度高，而耦合度低是指模塊之間的緊密程度低。在Struts 1的業務邏輯控制器Action中充斥著大量的Servlet API，使得業務邏輯控制器Action與Servlet API耦合度高。下面是一段Struts 1的Action代碼。

        public class LoginAction extends Action {
              public ActionForward execute(ActionMapping mapping, ActionForm form,
                        HttpServletRequest request, HttpServletResponse response) {
                        //獲得ActionForm的實例，其中封裝了用戶請求的參數
                        LoginForm loginForm = (LoginForm)form;
                        //取得用戶請求的參數
                        String name = loginForm.getUname();
                        String password = loginForm.getUpassword();
                        //new一個LoginCheck對象
                        LoginCheck lc = new LoginCheck();
                        //調用業務邏輯組件的判斷功能來判斷
                        if(lc.isLogin(name, password)){
                                //如果為合法用戶，在request范圍中添加屬性login，其屬性值為true，
                                并設定跳轉的邏輯視圖為"success"的頁面
                                  request.setAttribute("login", "true");
                                  return   mapping.findForward("success");
                            }else{
                                  //并設定跳轉的邏輯視圖為"failure"的頁面
                                  return mapping.findForward("failure");
                            }
              }

代碼中的execute方法需要4個參數，分別為ActionMapping、ActionForm、HttpServletRequest、HttpServletResponse。其中HttpServletRequest和HttpServletResponse屬于Servlet API，這樣使得業務邏輯控制器Action與Servlet API緊密程度高，也就是說Action與Servlet API耦合度高。

如果要測試該Action的execute方法，就必須要初始化這4個參數，這個初始化是非常困難的。而且其中的HttpServletRequest和HttpServletResponse兩個參數是由Web容器負責實例化的，一旦脫離Web服務器，測試就會變得異常困難。

（2）代碼依賴于Struts 1 API，難以擴展。

Struts 1中的業務邏輯組件必須繼承Struts 1的Action基類，FormBean必須繼承基類ActionForm。業務邏輯組件Action的execute方法包含大量的Struts 1 API，如ActionMapping、ActionForm以及ActionForward。這使得項目如果要重構時，這些Action就完全失去了利用價值。

（3）飽受爭議的ActionFrom。

大部分的開發人員都在為ActionForm是否應該存在問題而爭議著。因為ActionForm和自定義的JavaBean（PO、VO）有著重復的內容。雖然后來可以在Struts 1中使用動態ActionForm，但是根本問題還是沒有解決。開發者可能是在重新創建已經存在的JavaBean，不過仍然會導致有冗余的Javabean。

（4）表示層技術單一。

因為Struts 1出現的年代太早了，那時候還沒有出現FreeMarker、Velocity等表示層技術，所以使得Struts 1只能使用單一JSP作為表示層。

（5）表達式語言的選擇。

Struts 1中整合了JSTL，因此使用JSTL EL。這種EL有基本對象圖遍歷，但是對集合和索引屬性的支持很弱。

2.1.2 Struts 2簡介

Struts 2是Struts的下一代產品。而最初提案Struts Ti所設想的發展方向，在Struts現有代碼的基礎上是很難完成的。在發起提案的時候，Patrick Lightbody把多個不同的Web框架的領導者邀請到了一起，希望大家能夠達成共識，協力完成一個通用框架。雖然最終由于各種原因，Patrick Lightbody的愿望未能實現，但是WebWork和Struts卻發現了二者在技術與開發人員這兩個層面上的共同之處，不久之后，兩個項目就在WebWork的技術基礎上進行了合并，一個全新的Struts 2框架就這樣誕生了，如圖2.1所示。

圖2.1 Struts 2的起源

Struts 2的體系結構與Struts 1的體系結構的差別是巨大的。Struts 2是以WebWork為核心，采用攔截器的機制來處理用戶請求的，這樣的設計也是可以使得業務邏輯控制器能夠與Selvet API完全地脫離開，因此Struts 2可以理解為是WebWork的更新產品。因為Struts 2相比于Struts 1來說有著太大的變化，但是相對于WebWork, Struts 2只有很小的變化，所以如果是以前的WebWork開發人員，則能方便地過渡過來，但是相對于Struts 1開發人員，這種過渡會比較困難，相當于再學習一個新的框架。