一、框架的本質
在說Struts2，Spring和Hibernate核心原理之前，我覺得應該先搞明白以下三個問題，簡短概括如下：
1、什麼框架？
框架並不是什麼神聖的東西，它只是一組jar包而已，其本質是對jdk功能的擴展，包含了一系列最佳實踐，作用是解決某個領域的問題。
從廣義上說，jdk也可以看做一個複合框架，它提供的api同樣是爲了解決各個領域的問題，例如java io解決文件操作的問題，java socket解決網絡通訊的問題等等。
2、框架從何而來？
從框架的本質看，框架的產生就是爲了解決一個又一個在開發中所遇到的問題。不同的框架是爲了解決不同領域的問題。
3、爲什麼要使用框架？
框架是因解決問題而來，而且它帶來了解決某一領域問題的最佳實踐，實際是無數程序員在經過了無數次嘗試後，總結出來處理特定問題的特定方法，如果我們把每個程序員的自由發揮看做是一條通往成功的路徑，最佳實踐就是其中的最短路徑，它能夠極大地解放生產力。
二、框架的適用範圍
Web開發模式中最普遍的一種是“分層開發模式”，分層開發模式是指，在開發J2ee程序時，將整個程序根據功能職責進行縱向劃分，比較常見的劃分方法是：表示層，業務層，持久層。具體不再贅述，做java web開發，這是基本常識了。根據業務需求作用域的不同，這種分層會產生不同程度的變化，可能會細化更多層，也可能會合並，不能爲了分層而分層，一切脫離業務架構的設計都是虛幻的。
我們最爲熟悉得Struts，Spring，Hibernate正是爲了應對各個層次的編程問題的最佳實踐。即Struts對應表示層，Hibernate對應持久層，而Spring比較特殊，我們暫時簡單地認爲它對應業務層，後面我們再詳細討論。
三、Struts2
說了這麼多，終於進入文章的重心了。
從宏觀看，Struts2是一個運行於Web容器的表示層框架，其核心作用是幫助我們處理http請求。
Struts2遵循Servlet標準，通過實現標準的Filter接口進行Http請求的處理，通過在web.xml指定這個實現類StrutsPrepareAndExecuteFilter，就可以將Struts2引入到應用中來。
而Filter的生命週期也成爲我們對整個Struts2進行邏輯主線劃分的主要依據。
主線1：Struts2初始化-----Filter的init方法驅動執行。
主線2：Struts2處理Http請求------Filter的doFilter方法驅動
示意圖：
1、Struts2初始化
Struts2初始化只在web容器啓動時執行一次，啓動的成敗關係整個web應用的啓動成敗。初始化主線貫穿Struts2對其內置對象的創建和緩存過程，將Struts2的運行環境完整地創建起來。
我們從“數據”和“行爲”兩個角度來分析，構成Struts2整個初始化過程的主要元素，就可以分爲“數據結構的定義”和“初始化行爲的操作接口”兩部分。
（1）從數據結構定義的角度，Struts2圍繞管理Struts2內置對象的容器展開，該容器成爲初始化主線中的核心構成元素。而另一類配置元素PackageConfig作爲事件請求映射的配置元素也可作爲構成元素。接口定義和實現類分別爲：Container，ContainerImp，PackageConfig。
（2）從初始化行爲的操作接口的角度，則由另外兩個元素完成，加載接口和構造器。接口爲：ConfigurationProvider（使用多重繼承將Container和PackageConfig兩類配置加載接口進行統一），ContainerProvider（Container的配置加載接口，其實現類需要負責初始化容器中的所有對象），PackageProvider（PackageProvider接口，其實現類負責初始化用於處理事件請求的配置對象），ContainerBuilder（Container構造器，用於初始化時構造容器），PackageConfigBulider（PackageProvider構造器，用於初始化時構造PackageProvider）
還有兩個輔助元素承載上述接口，驅動整個初始化流程：ConfigurationManager（配置行爲操作代理類，包含所有ContainerProvider和PackageProvider的實現以及配置的結構化數據Configuration），Configuration（配置數據的管理類，運行時獲取配置的基本接口，承載所有配置的結構化數據和操作方法）
初始化步驟詳細示意圖
2、Struts2處理Http請求
Struts2處理Http請求又分兩個階段：Http請求預處理階段（以後統稱階段1），XWork執行業務邏輯（以後統稱階段2）
嚴格意義上說，Struts2是由兩個不同的框架組成，一個是執行在階段1的Struts2，負責將Web容器與MVC分離，，一個是執行在階段2的XWork，真正的MVC實現。
（1）階段1的主要元素
Dispatcher，整個Struts2的核心，被稱爲核心分發器，是Struts2進行http請求預處理的核心場所，更是將Http請求與web容器解耦並進行邏輯處理轉發的執行驅動中心。
PrepareOperations,HTTP預處理類，進行Http請求預處理的操作集合
ExecuteOperations，HTTP處理執行類，進行Http請求邏輯處理的操作集合
（2）階段2的主要元素
這一階段，程序控制權交給了XWork框架，涉及XWork框架的七大元素，這七大元素構成一條生產線，完成對http請求的處理。
ActionProxy，整個生產線的入口，封裝了所有執行細節。
ActionInvocation，生產線的調度者，負責調度整個生產線中各個元素的執行次序。
Interceptor，生產線上的工序，豐富生產線的功能。
Action，生產線上的核心工序，負責核心業務邏輯的調用或實現。
ActionContext，提供整個生產線需要的數據環境。
ValueStack，提供表達式計算的工具類，Xwork數據訪問的基礎。（後面細說）
Result，生產線末端設備，輸出生產線的生產結果。
結合階段1的核心分發器，根據七大元素的調用關係，我們可以得到如下示意圖：
從圖中，我們可以看出以下幾點：
（1）Dispatcher是Xwork框架的調用者和驅動者
（2）XWork生產線依賴兩個數據流：ActionContext和ValueStack
ActionContext是一個獨立的數據結構，無論是請求參數，處理返回值，甚至一些遠程的Web容器對象，都被封裝在ActionContext內部，成爲XWork執行所依賴的數據基礎。值得注意的是，ActionContext採用ThreadLocal保證線程安全。
ValueStack本身也是一個數據結構,從屬於ActionContext，主要是對OGNL計算進行擴展，因此，位於ActionContext之中的ValueStack則賦予了ActionContext進行數據計算的功能，從而使得ValueStack自身成爲一個可以進行數據訪問的環境。
插入一點OGNL相關的東西。
如果我們要數據在View層和java世界中互相流轉，就回在“字符串”和“對象樹”之間存在不匹配性，這個不匹配性源於Web是一個“弱類型”的平臺，而java卻是一個具有豐富數據類型的“強類型”的平臺。同一個對象在兩個平臺之間交互，就必須要一個“翻譯”，也就是我們說的“表達式引擎”，它充當着“翻譯橋樑”的作用，保證數據能夠順利地在MVC的各個層次進行流轉。而OGNL就是Struts2選擇的表達式引擎。
（3）XWork生產線所依賴的控制流：事件處理驅動元素-----ActionProxy，ActionInvocation，事件處理節點-----Interceptor，Action， Result
有關這五大元素的作用和關係，我們用下面這個比喻來詮釋。
四、本篇總結
至此，我們圍繞初始化和處理Http請求兩大主線說明Struts作爲表示層框架的基本原理，用一張圖概括本篇脈絡
隨着知識的積累，理解自然深入，下篇，我們將繼續探究Hibernate的核心原理……
轉自：http://blog.csdn.net/shan9liang/article/details/9281967