【正文】 Action 是單例模式并且必須是線程安全的，因為僅有 Action 的一個實例來處理 所有的請求。單例策略限制了 Struts1 Action 能作的事，并且要在開發(fā)時特別小心。 Action 資源必須是線程安全的或同步的。 Struts2 Action 對象為每一個請求產(chǎn)生一個實例，因此沒有線程安全問題。（實際上， servlet 容器給每個請求產(chǎn)生許多可丟棄的對象，并且不會導致性能和垃圾回收問題） (3)Servlet依賴： Struts1 Action 依 賴 于 Servlet API ， 因 為 當 一 個 Action 被調(diào)用時HttpServletRequest 和 HttpServletResponse 被傳 遞給 execute 方法。 Struts 2 Action 不依賴于容器，允許 Action 脫離容器單獨被測試。如果需要，Struts2 Action 仍然可以訪問初始的 request 和 ，其他的元素減少或者消除了直接訪問 HttpServetRequest 和 HttpServletResponse 的必要性。 (4)可測性： 測試 Struts1 Action 的一個主要問題是 execute 方法暴露了 servlet API（這使得測試要依賴于容器）。一個第三方擴展 —— Struts TestCase— — 提供了一套 Struts1 的模擬對象（來進行測試）。 Struts 2 Action 可以通過初始化、設(shè)置屬性、調(diào)用方法來測試， “ 依賴注入 ” 支持也使測試更容易。 (5)捕獲輸入： Struts1 使用 ActionForm 對象捕獲輸入。所有的 ActionForm 必須繼承一個基類。因為其他 JavaBean不能用作 ActionForm，開發(fā)者經(jīng)常創(chuàng)建多余的類捕獲輸入。動態(tài) Bean（ DynaBeans）可以作為創(chuàng)建傳統(tǒng) ActionForm 的選擇，但是，開發(fā)者可能是在重新描述（創(chuàng)建）已經(jīng)存在的 JavaBean（仍然會導 致有冗余的 javabean）。 Struts 2 直接使用 Action 屬性作為輸入屬性，消除了對第二個輸入對象的需求。輸入屬性可能是有自己（子）屬性的 rich 對象類型。 Action 屬性能夠通過 web 頁面上的 taglibs 訪問。 Struts2 也支持 ActionForm 模式。 rich 對象類型，包括業(yè)務對象，能夠用作輸入 /輸出對象。這種 ModelDriven 特性簡化了 taglib 對 POJO 輸入對象的引用。 (6)表達式語言： Struts1 整合了 JSTL，因此使用 JSTL EL 有基本對象圖遍歷，但是對 集合和索引屬性的支持很弱。 6 Struts2 可以使用 JSTL，但是也支持一個更強大和靈活的表達式語言 —— Object Graph Notation Language （ OGNL）。 (7)綁定值到頁面（ view）： Struts 1 使用標準 JSP 機制把對象綁定到頁面中來訪問。 Struts 2 使用 ValueStack技術(shù)，使 taglib 能夠訪問值而不需要把你的頁面（ view）和對象綁定起來。 ValueStack 策略允許通過一系列名稱相同但類型不同的屬性重用頁面（ view）。 類型轉(zhuǎn)換： Struts 1 ActionForm 屬性通常都是 String 類型。 Struts1 使用CommonsBeanutils 進行類型轉(zhuǎn)換。每個類一個轉(zhuǎn)換器，對每一個實例來說是不可配置的。 Struts2 使用 OGNL 進行類型轉(zhuǎn)換。提供基本和常用對象的轉(zhuǎn)換器。 校驗： Struts 1支持在 ActionForm的 validate方法中手動校驗，或者通過 Commons Validator 的擴展來校驗。同一個類可以有不同的校驗內(nèi)容，但不能校驗子對象。 Struts2 支持通過 validate 方法和 XWork 校驗框架來進行校驗。 XWork 校驗框架使用為屬性類類型定義的校驗和內(nèi)容校驗，來支持 chain 校驗子屬性 Action 執(zhí)行的控制：Struts1 支持每一個模塊有單獨的 Request Processors（生命周期），但是模塊中的所有 Action 必須共享相同的生命周期。 Struts2 支持通過攔截器堆棧（ Interceptor Stacks）為每一個 Action 創(chuàng)建不同的生命周期。堆棧能夠根據(jù)需要和不同的 Action 一起使用。 Struts2 的工作流程圖 圖 21 工作流程圖 工作流程當接收到一個 request Interceptor 做一些攔截或者初始的工作當外 7 部的 ervletrequest 到來時初始到了 servlet 容器 傳遞給一個標準的過濾器鏈ActionContextCleanUp 這個在集成插件方面非常有用 Other filters（ SitMesh， etc） 調(diào)用 FilterDispatecher 會去查找相應腁 ctionMapper 如果找到了相應的ActionMapper 它將會將控制權(quán)限交給 ActionProxy ActionProxy 將會通過ConfigurationManager 來查找配置 下一步將會 通過 ActionInvocation 來負責命令模式的實現(xiàn)（包括調(diào)用一些攔截 Interceptor 框架在調(diào)用 action 之前） 一旦 action 返回，會查找相應的 Result Result 類型可以是 jsp 或者 freeMark 等這些組件和 ActionMapper 一起返回給請求的 url（注意攔截器的執(zhí)行順序） 響應的返回是通過我們在 中配置的過濾器如果 ActionContextCleanUp 是當前使用的，則 FilterDispatecher 將不會清理 sreadlocal ActionContext 如果ActionContextCleanUp 不使用，則將會去清理 sreadlocals。 Hibernate 技術(shù)的簡介 Hibernate 是一個開放源代碼的對象關(guān)系映射框架，它對 JDBC 進行了非常輕量級的對象封裝，使得 Java 程序員可以隨心所欲的使用對象編程思維來操縱數(shù)據(jù)庫。 Hibernate 可以應用在任何使用 JDBC 的場合，既可以在 Java 的客戶端程序使用，也可以在 Servlet/JSP 的 Web 應用中使用，最具革命意義的是， Hibernate 可以在應用 EJB的 J2EE 架構(gòu)中取代 CMP，完成數(shù)據(jù)持久化的重任。 Hibernate 的核心接口一共有 5 個，分別為 :Session、 SessionFactory、Transaction、 Query 和 Configuration。這 5 個核心接口在任何開發(fā)中都會用到。通過這些接口，不僅可以對持久化對象進行存取，還能夠進行事務控制。下面對這五的核心接口分別加以介紹。 (1)Session接口 :Session接口負責執(zhí)行被持久化對象的 CRUD操作 (CRUD的任務是完成與數(shù)據(jù)庫的交流，包含了很多常見的 SQL 語句。 )。但需要注意的是 Session 對象是 非線程安全的。同時， Hibernate 的 session 不同于 JSP 應用中的 HttpSession。這里當使用 session 這個術(shù)語時，其實指的是 Hibernate 中的 session，而以后會將HttpSesion 對象稱為用戶 session。 (2)SessionFactory 接口 :SessionFactroy 接口負責初始化 Hibernate。它充當數(shù)據(jù)存儲源的代理，并負責創(chuàng)建 Session 對象。這里用到了工廠模式。需要注意的是SessionFactory 并不是輕量級的，因為一般情況下，一個項目通常只需要一 個SessionFactory 就夠，當需要操作多個數(shù)據(jù)庫時，可以為每個數(shù)據(jù)庫指定一個SessionFactory。 (3)Configuration 接口 :Configuration 接口負責配置并啟動 Hibernate，創(chuàng)建SessionFactory 對象。在 Hibernate 的啟動的過程中， Configuration 類的實例首先定 8 位映射文檔位置、讀取配置，然后創(chuàng)建 SessionFactory 對象。 (4)Transaction 接口 :Transaction 接口負責事務相關(guān)的操作。它是可選的，開發(fā)人員也可以 設(shè)計編寫自己的底層事務處理代碼。 (5)Query 和 Criteria 接口 :Query 和 Criteria 接口負責執(zhí)行各種數(shù)據(jù)庫查詢。它可以使用 HQL 語言或 SQL 語句兩種表達方式。 Spring 技術(shù)的介紹 Spring 是一個開源框架，它由 Rod Johnson 創(chuàng)建。它是為了解決企業(yè)應用開發(fā)的復雜性而創(chuàng)建的。 Spring 使用基本的 JavaBean 來完成以前只可能由 EJB 完成的事情。然而， Spring 的用途不僅限于服務器端的開發(fā)。從簡單性、可測試性和松耦合的角度而言，任何 Java 應用都可以從 Spring 中受益。 簡單來說， Spring 是一個輕量級的控制反轉(zhuǎn) (IoC)和面向切面 (AOP)的容器框架。 輕量 —— 從大小與開銷兩方面而言 Spring 都是輕量的。完整的 Spring 框架可以在一個大小只有 1MB 多的 JAR 文件里發(fā)布。并且 Spring 所需的處理開銷也是微不足道的。此外， Spring 是非侵入式的：典型地， Spring 應用中的對象不依賴于 Spring 的特定類。 控制反轉(zhuǎn) —— Spring 通過一種稱作控制反轉(zhuǎn)（ IoC）的技術(shù)促進了松耦合。當應用了 IoC，一個對象依賴的其它對象會通過被動的方式傳遞進來，而不是 這個對象自己創(chuàng)建或者查找依賴對象。你可以認為 IoC 與 JNDI 相反 —— 不是對象從容器中查找依賴，而是容器在對象初始化時不等對象請求就主動將依賴傳遞給它。 面向切面 —— Spring 提供了面向切面編程的豐富支持，允許通過分離應用的業(yè)務邏輯與系統(tǒng)級服務（例如審計（ auditing）和事務（ transaction）管理）進行內(nèi)聚性的開發(fā)。應用對象只實現(xiàn)它們應該做的 —— 完成業(yè)務邏輯 —— 僅此而已。它們并不負責（甚至是意識）其它的系統(tǒng)級關(guān)注點，例如日志或事務支持。 容器 —— Spring 包含并管理應用對象的配置和生命周期 ，在這個意義上它是一種容器，你可以配置你的每個 bean 如何被創(chuàng)建 —— 基于一個可配置原型（ prototype），你的 bean 可以創(chuàng)建一個單獨的實例或者每次需要時都生成一個新的實例 —— 以及它們是如何相互關(guān)聯(lián)的。然而， Spring 不應該被混同于傳統(tǒng)的重量級的 EJB 容器，它們經(jīng)常是龐大與笨重的，難以使用。 框架 —— Spring 可以將簡單的組件配置、組合成為復雜的應用。在 Spring 中，應用對象被聲明式地組合，典型地是在一個 XML文件里。 Spring 也提供了很多基礎(chǔ)功能（事務管理、持久化框架集成等等），將應用邏輯的 開發(fā)留給了你。 所有 Spring 的這些特征使你能夠編寫更干凈、更可管理、并且更易于測試的代碼。它們也為 Spring 中的各種模塊提供了基礎(chǔ)支持。 9 B/S 模式的介紹及應用 什么是 B/S 模式 本系統(tǒng)采用 B/S 模式。 B/S（ Browser/Server）結(jié)構(gòu)即瀏覽器和服務器結(jié)構(gòu)。它是隨著 Inter 技術(shù)的興起，對 C/S 結(jié)構(gòu)的一種變化或者改進的結(jié)構(gòu)。在這種結(jié)構(gòu)下，用戶工作界面是通過 WWW 瀏覽器來實現(xiàn)，極少部分事務邏輯在前端（ Browser）實現(xiàn)，但是主要事務邏輯在服務器端（ Server） 實現(xiàn)，形成所謂三層 3tier 結(jié)構(gòu)。這樣就大大簡化了客戶端電腦載荷，減輕了系統(tǒng)維護與升級的成本和工作量，降低了用戶的總體成本（ TCO）。以目前的技術(shù)看，局域網(wǎng)建立 B/S 結(jié)構(gòu)的網(wǎng)絡應用，并通過Inter/Intra 模式下數(shù)據(jù)庫應用，相對易于把握、成本也是較低的。它是一次性到位的開發(fā)，能實現(xiàn)不同的人員，從不同的地點，以不同的接入方式（比如 LAN， WAN，Inter/Intra 等）訪問和操作共同的數(shù)據(jù)庫；它能有效地保護數(shù)據(jù)平臺和管理訪問權(quán)限，服務器數(shù)據(jù)庫也很安全。特別是在 JAVA 這樣的跨平 臺語言出現(xiàn)之后， B/S架構(gòu)管理軟件更是方便、快捷、高效。 B/S 模式的優(yōu) 點 (1) 維護和升級方式簡單 目前，軟件系統(tǒng)的改進和升級越來越頻繁， B/S 架構(gòu)的產(chǎn)品明顯體現(xiàn)著更為方便的特性。對一個稍微大一點的單位來說，系統(tǒng)管理人員如果需要在幾百甚至上千部電腦之間來回奔跑，效率和工作量是可想而知的，但 B/S 架構(gòu)的軟件只需要管理服務器就行了，所有的客戶端只是瀏覽器，根本不需要做任何的維護。無論用戶的規(guī)模有多大，有多少分支機構(gòu)都不會增加任何維護升級的工作量，所有的操作只需要針對服務器進行；如果是異地，只 需要把服務器連接專網(wǎng)即可，實現(xiàn)遠程維護、升級和共享。所以客戶機越來越“瘦”，而服務器越來越“胖”是將來信息化發(fā)展的主流方向。今后，軟件升級和維護會越來越容易，而使用起來會越來越簡單，這對用戶人力、物力、時間、費用的節(jié)省是顯而易見的，驚人的。因此，維護和升級革命