終結章開始咯——【模式和Struts】，模式介紹還算精彩，Struts雖然現在版本變化很多，不過作爲了解性的介紹也還是可以的:)
134、軟件設計模式是“對”常見軟件問題的一種可重複的解決方案（P709）；
135、你很可能遇到的3個主要的非功能需求：
1）性能；
2）模塊性：爲了讓應用的不同部分能同時在不同的主機上運行，你的軟件必須是模塊化的……而且要以適當的方式模塊化；
3）靈活性（不僅能修改系統，而且無需經過太長的開發週期）、可維護性（想換個數據庫開發商並能以最快速度完成系統更新，遇到一些不太明確的bug想盡快跟蹤出來……）和可擴展性。（P710）；
136、對象跨網絡通信時存在一些問題，Java和J2EE提供了一些機制，可以解決其中最常見的兩個難題：查找遠程對象，以及處理本地和遠程對象之間的底層網絡I/O通信（換句話說，如何找到遠程對象，以及如何調用其方法）（P715）；
137、JNDI核心手冊：Java Naming and Directory Interface，這是一個訪問命名和目錄服務的API，基於JNDI，可以在網絡中的一個集中位置上完成查找。如果你有一些對象，而且希望網絡上的其他程序找到並訪問這些對象，就要向JNDI註冊這些對象。其他程序想使用你的對象，則可以使用JNDI來查找。
RMI核心手冊：Remote Method Invocation，利用這種機制，獲得對象並跨網絡通信的過程就能大大簡化，希望一個JVM中的對象調用一個遠程對象上的方法，但是，你想假裝成好像調用本地對象的方法一樣，這正是RMI的作用。（P715~716）；
138、服務器端RMI的4大步驟：
1）創建一個遠程接口，getCustData()之類的方法簽名就放在這裏，樁（代理）和具體的模型服務（遠程對象）要實現這個接口。
2）創建遠程實現，換句話說，具體的模型對象放在模型服務器上，這一步還包括向一個已知註冊服務（如JNDI或RMI註冊表）註冊模型。
3）生成樁，還可能生成骨架。RMI提供了一個名爲rmic的編譯器，會爲你創建代理。
4）啓動/運行模型服務（它會自行向註冊表註冊，並等待遠程客戶的調用）。（P717）；
139、使用和不使用RMI客戶端僞代碼：
| 不使用RMI客戶 | 使用RMI客戶 |
|---|---|
|
public void goClient () { try{ //得到一個新的Socket
//得到一個OutputStream //把它鏈到一個ObjectOutputStream
//發送opcode及op參數 //刷新輸出OS（輸出流）
//得到InputStream //把它鏈到一個ObjectInputStream
//讀取返回值和/或 //處理異常
//完成關閉工作
}//捕獲和處理遠程異常 } |
public void goClient() { try｛ //查找遠程對象（樁）
//調用遠程對象方法
｝//捕獲和處理遠程異常 } |
（P717too）；
140、使用遠程對象的3個步驟：
1）模型向JNDI服務註冊；
2）控制器得到一個請求，控制器代碼完成一個JNDI查找，得到遠程模型服務的樁代理；
3）控制器在樁上完成業務方法調用，就好像樁是真正的模型對象一樣。（P718）；
141、控制器與樁的“中間”對象——業務委託（僞代碼如下：）
//得到請求，並完成一個JNDI查找
//得到一個樁
//調用業務方法
//處理並抽出所有遠程異常
//把返回值發送給控制器
（P721）；
142、把業務委託中處理查找服務的重複代碼抽出成——服務定位器（僞代碼如下：）。
讓業務委託對象只處理業務方法，而不要同時處理註冊查找，這樣就能提高業務委託的內聚度。
//得到一個InitialContext對象
//完成遠程查找
//處理遠程問題
//還可能會緩存引用
（P722）；
143、遠程調用 6 步驟：
1、向JNDI註冊服務；
2）使用業務委託和服務器定位器從JNDI得到管理顧客樁；
3）使用業務委託和樁來得到顧客“bean”，在這裏，顧客也是一個樁，把這個樁的引用返回給控制器；
4）將顧客樁引用增加到請求；
5）控制器轉發到視圖Jsp。Jsp從請求對象得到對顧客bean（樁）的一個引用；
6）視圖Jsp使用EL得到所需的顧客bean性質，來滿足最初的請求。
重要提示：JSP每次調用一個獲取方法時，顧客樁都會做一個網絡調用。
（P725）；
144、可能會要求一個業務服務通過一個很大的粗粒度消息來發送或接收全部或大部分數據，爲此，這個服務一般會在API中提供這個特性。通常，業務服務會創建一個可串行化的Java對象，其中包含大量實例變量。Sun把這個對象稱爲傳輸對象。（P727）；
145、傳輸對象中的數據會過時！
一旦經網絡傳輸，傳輸對象就與其來源完全失去聯繫，而且與底層數據庫中的數據狀態不再同步。你必須針對各個用例來確定：到底是數據的完整性/同步重要，還是性能更重要。（P727too）；
146、MVC在 www 誕生之前就已存在。最初，MVC只是一種用於簡化複雜GUI應用的設計。最早在Smalltalk中創建，MVC主要的特點之一就是視圖會自動得到通知，可以瞭解到模型的變化。
最近Web 上也使用MVC，不過視圖在瀏覽器中，當Web 層中的模型有變化時瀏覽器中的視圖不會自動更新。我們關注的就是Web版本的MVC。
模型：保存真正的業務邏輯和狀態，換句話說，它瞭解獲取和更新狀態的規則。（應用中只有這部分會與數據庫通信。）
視圖：表示都由視圖負責，它從控制器得到模型的狀態（儘管不是直接得到；控制器會把模型數據放在視圖能找到的一個位置上。）
控制器：從請求取得用戶輸入，並向模型明確用戶輸入的含義。告訴模型自行更新【使視圖（JSP）可以得到模型的狀態】，並轉發到JSP（P730）；
147、控制器 3 大任務：
1）獲取和處理請求參數；
2）調用模型；
3）分派到視圖。（P733）；
148、框架是一些接口和類的集合，這些接口和類設計爲一同處理某種特定類型的問題。（對於Struts，問題空間就是Web應用）（P736）；
149、前端控制器也是一種J2EE模式，基本思想是：一個組件（通常Servlet）作爲Web應用表示層的一個控制點。採用前端控制器模式，則應用的所有請求都會通過一個控制器，由它處理，並將請求分派到適當的地方。(P737)；
150、前端控制器特性：
1）把Web應用的初始化請求處理任務都集中在一個組件中完成。
2）結合其他模式使用前端控制器時，可以採用聲明方式建立表示層的分派，從而提供鬆耦合。（P751）
至此，終結章採收完成。o(∩_∩)o