1. 程式人生 > >javaEE之SSH框架的底層機制及原理

javaEE之SSH框架的底層機制及原理

Struts1工作原理圖:
                               

1、初始化:struts框架的總控制器ActionServlet是一個Servlet,它在web.xml中配置成自動啟動的Servlet,在啟動時總控制器會讀取配置檔案(struts-config.xml)的配置資訊,為struts中不同的模組初始化相應的物件。(面向物件思想)

2、傳送請求:使用者提交表單或通過URL向WEB伺服器提交請求,請求的資料用HTTP協議傳給web伺服器。

3、form填充:struts的總控制器ActionServlet在使用者提交請求時將資料放到對應的form物件中的成員變數中。

4、派發請求:控制器根據配置資訊物件ActionConfig將請求派發到具體的Action,對應的formBean一併傳給這個Action中的excute()方法。

5、處理業務:Action一般只包含一個excute()方法,它負責執行相應的業務邏輯(呼叫其它的業務模組)完畢後返回一個ActionForward物件。伺服器通過ActionForward物件進行轉發工作。

6、返回響應:Action將業務處理的不同結果返回一個目標響應物件給總控制器。

7、查詢響應:總控制器根據Action處理業務返回的目標響應物件,找到對應的資源物件,一般情況下為jsp頁面。

8、響應使用者:目標響應物件將結果傳遞給資源物件,將結果展現給使用者。


系統從職責上分為四層:表示層、業務邏輯層、資料持久層和域模組層。其中使用Struts作為系統的整體基礎架構,負責MVC的分離,在Struts框架的模型部分,利用框架對持久層提供支援,業務層用支援。具體做法是:用面向物件的分析方法根據需求提出一些模型,將這些模型實現為基本的Java物件,然後編寫基本的DAO介面,並給出HibernateDAO實現,採用 Hibernate架構實現的DAO類來實現Java類與資料庫之間的轉換和訪問,最後由Spring完成業務邏輯。
系統的基本業務流程是:在表示層中,首先通過JSP頁面實現互動介面,負責傳送請求(Request)和接收響應(Response),然後Struts

根據配置檔案(struts-config.xml)ActionServlet接收到的Request委派給相應的Action處理。在業務層中,管理服務元件的 Spring IoC容器負責向Action提供業務模型(Model)元件和該元件的協作物件資料處理(DAO)元件完成業務邏輯,並提供事務處理、緩衝池等容器元件以提升系統性能和保證資料的完整性。而在持久層中,則依賴於Hibernate的物件化對映和資料庫互動,處理DAO元件請求的資料,並返回處理結果。
  採用上述開發模型,不僅實現了檢視、控制器與模型的徹底分離,而且還實現了業務邏輯層與持久層的分離。這樣無論前端如何變化,模型層只需很少的改動,並且資料庫的變化也不會對前端有所影響,大大提高了系統的可複用性。而且由於不同層之間耦合度小,有利於團隊成員並行工作,大大提高了開發效率。

Struts1struts2有什麼不同

1.Action
 Stuts1要求Action類繼承一個抽象基類。Struts1的一個普通問題是使用抽象類程式設計而不是介面。Struts2 Action類可以實現一個Action介面,也可以實現其它介面,使可選和定製的服務成為可能。Struts2提供一個ActionSupport基類去實現常用的介面。Action 介面不是必須的,任何有execute標識的POJO物件都可以用作Struts2的Action物件。

2. 執行緒模式:Struts1 Action是單例模式並且必須是執行緒安全的,因為僅有Action的一個例項來處理所有的請求。單例策略限制了Struts1 Action能作的事,並且要在開發時特別小心。Action資源必須是執行緒安全的或同步的。 Struts 2 Action物件為每一個請求產生一個例項,因此沒有執行緒安全問題。

3.Servlet依賴:Struts1 Action依賴於Servlet API,因為當一個Action被呼叫時,HttpServletResquest和HttpServletResponse被傳遞給execute方法,即Action依賴了容器,測試變得非常麻煩。Struts2 Action不依賴於容器,允許Action脫離容器單獨被測試。如果需要,Struts2 Action仍然可以訪問初始的request和response。但是,其它的元素減少或者消除了直接訪問HttpServletRequset和HttpServletResponse的必要性。 4.捕獲輸入:Struts1使用ActionForm物件捕獲輸入。所有的ActionForm必須繼承一個基類。因為其它JavaBean不能用作ActionForm,開發者經常建立多餘的類捕獲輸入。動態Bean可以作為建立傳統ActionForm的選擇,但是,開發者可能是在重新描述已經存在的JavaBean,仍然會導致有冗餘的javabean。Struts2直接使用Action屬性作為輸入屬性,消除了對第二輸入物件的需求。Action屬效能夠通過web頁面上的taglibs訪問。Struts2也支援ActionForm模式。(Struts2用普通的POJO來接收資料)

5.表示式語言:Struts1整合了JSTL,但對集合和索引屬性的支援很弱。Struts2可以是使用JSTL,但是也支援一個更加強大和靈活的表示式語言 “Object Graph Notation Language”(OGNL—物件圖導航語言).

6. 繫結值到頁面(view: Struts1使用標準JSP機制把物件繫結到頁面中來訪問,Struts1要傳遞值的時候必須往request裡放、往session裡放,然後再傳遞到jsp裡面,el表示式得到。Struts2使用“ValueStack”技術,使taglib能夠訪問值而不需要把你的頁面和物件繫結起來。ValueStack策略允許通過一系列名稱相同但型別不同的屬性重用頁面。值棧技術非常著名。不需要request、不需要session,直接從Action中取值。

7.型別轉換: Struts1 ActionForm屬性通常都是String型別。Struts1使用Commons-Beanutils進行型別轉換。每個類一個轉換器,對每一個例項來說是不可配置的。Struts2 使用OGNL進行型別轉換。提供基本和常用物件的轉換器。
 

8.校驗:Struts1支援在ActionForm的validate方法中手動校驗,或者通過Commons Validator的擴充套件來校驗。同一個類可以有不同的校驗內容,但不能校驗子物件。Struts2支援通過validate方法和Xwork校驗框架來進行校驗。Xwork校驗框架使用為屬性類型別定義的校驗和內容校驗,來支援chain校驗子屬性。

9.Action執行的控制:Struts1支援每一個模組有單獨的RequestProcessors(生命週期),但是模組中的所有Action必須共享相同的生命週期。(伺服器重啟時,Action生命週期結束,即生命週期無法控制)。Struts2支援通過攔截器堆疊(Interceptor Stacks)為每一個Action建立不同的生命週期。堆疊能夠根據需要和不同的Action一起使用。(可以控制Action的生命週期)

簡單的說:
struts1 和struts2的核心原理不同:
struts1.X是基於servlet的
struts2是xwork的變體:他的核心是filter
struts1是單例模式開發,
struts2是多例模式。
struts1的單例模式好處是節省記憶體,缺點是併發性查,非同步。
struts2好處是執行緒安全是同步的每次使用開闢新的記憶體空間,缺點是佔用資源多。

Model1的原理:

Struts1的工作原理:

圖2

它引入了"控制器"這個概念,控制器一般由servlet來擔任,客戶端的請求不再直接送給一個處理業務邏輯的JSP頁面,而是送給這個控制器,再由控制器根據具體的請求呼叫不同的事務邏輯,並將處理結果返回到合適的頁面。因此,這個servlet控制器為應用程式提供了一個進行前-後端處理的中樞。一方面為輸入資料的驗證、身份認證、日誌及實現國際化程式設計提供了一個合適的切入點;另一方面也提供了將業務邏輯從JSP檔案剝離的可能。業務邏輯從JSP頁面分離後,JSP檔案蛻變成一個單純完成顯示任務的東西,這就是常說的View。而獨立出來的事務邏輯變成人們常說的Model,再加上控制器Control本身,就構成了MVC模式。實踐證明,MVC模式為大型程式的開發及維護提供了巨大的便利。

其實,MVC開始並不是為Web應用程式提出的模式,傳統的MVC要求M將其狀態變化通報給V,但由於Web瀏覽器工作在典型的拉模式而非推模式,很難做到這一點。因此有些人又將用於Web應用的MVC稱之為MVC2。正如上面所提到的MVC是一種模式,當然可以有各種不同的具體實現,包括您自己就可以實現一個體現MVC思想的程式框架,Struts就是一種具體實現MVC2的程式框架。它的大致結構如圖三所示:



圖三

圖三基本勾勒出了一個基於Struts的應用程式的結構,從左到右,分別是其表示層(view)、控制層(controller)、和模型層(Model)。其表示層使用Struts標籤庫構建。來自客戶的所有需要通過框架的請求統一由叫ActionServlet的servlet接收(ActionServlet Struts已經為我們寫好了,只要您應用沒有什麼特別的要求,它基本上都能滿足您的要求),根據接收的請求引數和Struts配置(struts-config.xml)中ActionMapping,將請求送給合適的Action去處理,解決由誰做的問題,它們共同構成Struts的控制器。Action則是Struts應用中真正幹活的元件,開發人員一般都要在這裡耗費大量的時間,它解決的是做什麼的問題,它通過呼叫需要的業務元件(模型)來完成應用的業務,業務元件解決的是如何做的問題,並將執行的結果返回一個代表所需的描繪響應的JSP(或Action)的ActionForward物件給ActionServlet以將響應呈現給客戶。

過程如圖四所示:



圖四

這裡要特別說明一下的是:就是Action這個類,上面已經說到了它是Struts中真正幹活的地方,也是值得我們高度關注的地方。可是,關於它到底是屬於控制層還是屬於模型層,存在兩種不同的意見,一種認為它屬於模型層,如:《JSP Web程式設計指南》;另一些則認為它屬於控制層如:《ProgrammingJakarta Struts》、《Mastering Jakarta Struts》和《Struts Kick Start》等認為它是控制器的一部分,還有其他一些書如《Strutsin Action》也建議要避免將業務邏輯放在Action類中,也就是說,圖3中Action後的括號中的內容應該從中移出,但實際中確有一些系統將比較簡單的且不打算重用的業務邏輯放在Action中,所以在圖中還是這樣表示。顯然,將業務物件從Action分離出來後有利於它的重用,同時也增強了應用程式的健壯性和設計的靈活性。因此,它實際上可以看作是Controller與Model的介面卡,如果硬要把它歸於那一部分,筆者更傾向於後一種看法,即它是Controller的一部分,換句話說,它不應該包含過多的業務邏輯,而應該只是簡單地收集業務方法所需要的資料並傳遞給業務物件。實際上,它的主要職責是:

·  校驗前提條件或者宣告

·  呼叫需要的業務邏輯方法

·  檢測或處理其他錯誤

·  路由控制到相關檢視

上面這樣簡單的描述,初學者可能會感到有些難以接受,下面舉個比較具體的例子來進一步幫助我們理解。如:假設,我們做的是個電子商務程式,現在程式要完成的操作任務是提交定單並返回定單號給客戶,這就是關於做什麼的問題,應該由Action類完成,但具體怎麼獲得資料庫連線,插入定單資料到資料庫表中,又怎麼從資料庫表中取得這個定單號(一般是自增資料列的資料),這一系列複雜的問題,這都是解決怎麼做的問題,則應該由一個(假設名為orderBo)業務物件即Model來完成。orderBo可能用一個返回整型值的名為submitOrder的方法來做這件事,Action則是先校驗定單資料是否正確,以免常說的垃圾進垃圾出;如果正確則簡單地呼叫orderBo的submitOrder方法來得到定單號;它還要處理在呼叫過程中可能出現任何錯誤;最後根據不同的情況返回不同的結果給客戶。

二、為什麼要使用Struts框架

既然本文的開始就說了,自己可以建這種框架,為什麼要使用Struts呢?我想下面列舉的這些理由是顯而易見的:首先,它是建立在MVC這種公認的好的模式上的,Struts在M、V和C上都有涉及,但它主要是提供一個好的控制器和一套定製的標籤庫上,也就是說它的著力點在C和V上,因此,它天生就有MVC所帶來的一系列優點,如:結構層次分明,高可重用性,增加了程式的健壯性和可伸縮性,便於開發與設計分工,提供集中統一的許可權控制、校驗、國際化、日誌等等;其次,它是個開源專案得到了包括它的發明者Craig R.McClanahan在內的一些程式大師和高手持續而細心的呵護,並且經受了實戰的檢驗,使其功能越來越強大,體系也日臻完善;最後,是它對其他技術和框架顯示出很好的融合性。如,現在,它已經與tiles融為一體,可以展望,它很快就會與JSF等融會在一起。當然,和其他任何技術一樣,它也不是十全十美的,如:它對類和一些屬性、引數的命名顯得有些隨意,給使用帶來一些不便;還有如Action類execute方法的只能接收一個ActionForm引數等。但瑕不掩瑜,這些沒有影響它被廣泛使用

為什麼使用Struts2 ?

新版本的Struts2.0是struts 的action架構和webwork的融合體.依照Struts2.0.1的釋出公告,一些關鍵特性如下 :

l設計簡單: 使用抽象類而不是介面是Struts1的一個設計上的問題,這已經在Struts2中得到了解決.在Struts2中絕大多數類都是基於介面的,並且它的絕大多數核心介面都是獨立於HTTP的.Struts2的Action類是獨立於框架的,可視為單純的POJO.框架的元件都設法保持鬆耦合

l單純的Action : Action都是單純的POJO.任何含有execute()方法的java類都可以當作Action類來使用.甚至我們始終都不需要實現介面.反轉控制會在開發Action類的時候得到介紹過,這能讓Action中立於底層框架.

l不再使用ActionForm : ActionForm特性不再在Structs2中出現.簡單的JavaBean即可對Action直接傳遞引數.不再需要全部使用String型別的引數.

l簡單的測試 : Struts2的Action是獨立於HTTP並且中立於框架的.這使得Struts2的程式可以很容易的在沒有模擬物件的情況下測試.

l巧妙的預設值 :大多數配置元素都設有一個根據需要設定的預設值.甚至根據需要基於XML的預設配置檔案都可以進行重寫.

l改良的結果集 : 不像Struts1中的ActionForward,Struts2的結果集靈活的提供了多種型別的輸出,事實上這促進了響應的準備工作.

l更好的標籤特性 : Struts2可以新增樣式表驅動標記,這使我們建立相同的頁面僅用更少的程式碼.Struts2的標籤更有效而且是面向結果的.Struts2的標籤標記可以通過修改基礎樣式表來修改.個別的標籤標記可以通過編輯FreeMarker的模板來修改.JSP和FreeMarker都完全得到了支援.

l引入註釋 : 在Struts2程式中,除了XML和Javaproperties 配置檔案外,Java 5的註釋也可以作為一種選擇.註釋使得XML的使用降至最低.

l有狀態的Checkbox : Struts2中的checkbox不需要對false值進行特殊處理.

l快速開始 :很多改變無需重啟web容器即可實現.

l自定義控制器 : Struts1可以自定義每一個模組的請求處理器,如果需要,Struts2可以自定義每一個Action的請求處理.

l易與Spring整合 : Struts2的Action與Spring是友好的,只需新增Spring的bean

l輕巧的外掛 : Struts2可以通過新增一個Jar檔案來進行擴充套件,不再需要手動配置!

l支援AJAX : AJAX主題對提升程式互動有著重要的意義.Struts2框架提供了一套標籤來AJAX化你的程式甚至DOJO.AJAX特性包括:

1.AJAX客戶端驗證.

2.支援遠端表單提交.(同樣適用於submit標籤)

3.先進的div模板提供動態過載部份HTML

4.的能力.

5.AJAX-only選項卡面板的實現

6.豐富的釋出/訂閱事件模型

7.自動互動完善標籤

一、 Struts概述

Struts是一個用來開發 Model2應用程式的框架。這個框架可以提高開發工作的速度,因為它提供的下面這些功能解決了 Web應用程式開發過程中的一些常見問題:

·        對頁面導航活動進行管理;

·        對來自使用者的輸入資料進行合法性驗證;

·        統一的佈局;

·        可擴充套件性;

·        國際化和本地化;

·        支援 Ajax技術。

因為 Struts是一個 Model 2框架,所以在使用 Struts時還應該遵守以下幾條不成文的規定。

·        不要在 JSP頁面裡嵌入 Java程式碼,應該把所有的業務邏輯包含在一些被稱為“動作類”( actionclass)的 Java類裡。

·        在 JSP頁面裡使用 Expression Language( OGNL)去訪問有關的模型物件。

·        儘量避免編寫自定義標籤(因為自定義標籤的程式碼比較難以編寫)。

二、升級到 Struts 2

你也許用過 Struts 1程式設計,這裡提供了一個關於 Struts2 新功能的簡要介紹。

·        在 Struts 1裡需要使用一個像ActionServlet 類這樣的東西作為 servlet控制器; Struct 2使用了一個過濾器來完成同樣的任務。

·        在 Struts 2裡沒有任何動作表單。在 Struts 1裡,每個 HTML表單都對應著一個 ActionForm 例項,你可以從動作類訪問這個動作表單,並用它來填充資料傳輸物件。在 Struts 2 裡, HTML表單將被直接對映為一個 POJO,而不再需要你建立一個數據傳輸物件,因為沒有動作表單,維護工作變得簡單容易了,你不再需要與那麼多的類打交道。

·        問題來了:沒有了動作表單,怎樣才能在 Struts 2裡通過程式設計對使用者輸入進行合法性驗證呢?答案是把驗證邏輯編寫在動作類裡

·        Struts 1通過幾個標籤庫提供了一批定製標籤供程式設計師在 JSP頁面裡使用,其中最重要的是 HTML標籤庫、 Bean標籤庫和 Logic標籤庫。 Servlet 2.4裡的 JSTL和EL( Expression Language ,表示式語言)經常被用來代替 Bean和 Logic標籤庫。Struts 2為程式設計師準備了一個應有盡有的標籤庫,你不再需要 JSTL,但在某些場合你可能仍需要 EL

·        在 Struts 1裡,你還需要用到一些 Struts配置檔案,其中最主要的是存放在各 Web應用程式裡的 WEB-INF子目錄裡的 struts-config.xml(預設檔名)。在 Struts 2裡,你仍需要用到多個配置檔案,但必須把它們存放在WEB-INF/classes子目錄或它的某個下級子目錄裡。

·        要想使用 Struts 2 ,你的系統裡必須有 Java 5 和 Servlet 2.4 (或更高版本)。之所以需要有 Java 5,是因為 Java 5裡新增加的註解在Struts 2裡扮演著重要角色。我們撰寫本書時, Java 6已經發布, Java 7也指日可待,你很可能已經在使用 Java 5或 Java 6了。

·        在 Struts 1 裡,動作類必須擴充套件自org.apache.struts.action.Action 類。在 Struts 2 裡,任何一個POJO 都可以是一個動作類。不過,我們將在本書第 3 章說明,在 Struts 2 裡最好對ActionSupport 類進行擴充套件。在此基礎上,可用一個動作類來完成相關的動作。

·        Struts2在 JSP頁面裡使用 OGNL來顯示各種物件模型,而不再是 JSP         EL和 JSTL。

原本是 Struts 1元件之一的 Tiles現在已經發展為一個獨立的 Apache

HTTP沒有“型別”的概念,在HTTP請求裡傳送的值都是字串。在把表單欄位對映到非 String 型別的動作屬性時, Struts會自動對這些值進行必要的轉換。這一章將解釋 Struts如何完成這類轉換,你還將學到如何為更加複雜的情

spring工作機制及為什麼要用?

  1.springmvc請所有的請求都提交給DispatcherServlet,它會委託應用系統的其他模組負責對請求進行真正的處理工作。

  2.DispatcherServlet查詢一個或多個HandlerMapping,找到處理請求的Controller.

  3.DispatcherServlet請求提交到目標Controller

  4.Controller進行業務邏輯處理後,會返回一個ModelAndView

  5.Dispathcher查詢一個或多個ViewResolver檢視解析器,找到ModelAndView物件指定的檢視物件

  6.檢視物件負責渲染返回給客戶端。

  為什麼用:

  AOP 讓開發人員可以建立非行為性的關注點,稱為橫切關注點,並將它們插入到應用程式程式碼中。使用 AOP後,公共服務(比如日誌、永續性、事務等)就可以分解成方面並應用到域物件上,同時不會增加域物件的物件模型的複雜性。

  IOC 允許建立一個可以構造物件的應用環境,然後向這些物件傳遞它們的協作物件。正如單詞 倒置所表明的,IOC 就像反過來的JNDI。沒有使用一堆抽象工廠、服務定位器、單元素(singleton)和直接構造(straightconstruction),每一個物件都是用其協作物件構造的。因此是由容器管理協作物件(collaborator)。

  Spring即使一個AOP框架,也是一IOC容器。 Spring 最好的地方是它有助於您替換物件。有了Spring,只要用JavaBean屬性和配置檔案加入依賴性(協作物件)。然後可以很容易地在需要時替換具有類似介面的協作物件。

  Spring 框架是一個分層架構,由 7 個定義良好的模組組成。Spring模組構建在核心容器之上,核心容器定義了建立、配置和管理bean 的方式,如圖 1 所示。

  組成 Spring 框架的每個模組(或元件)都可以單獨存在,或者與其他一個或多個模組聯合實現。每個模組的功能如下:

  核心容器:核心容器提供 Spring框架的基本功能。核心容器的主要元件是BeanFactory,它是工廠模式的實現。BeanFactory使用控制反轉(IOC)模式將應用程式的配置和依賴性規範與實際的應用程式程式碼分開。

  Spring 上下文:Spring 上下文是一個配置檔案,向 Spring框架提供上下文資訊。Spring上下文包括企業服務,例如 JNDI、EJB、電子郵件、國際化、校驗和排程功能。

  Spring AOP:通過配置管理特性,Spring AOP 模組直接將面向方面的程式設計功能整合到了Spring框架中。所以,可以很容易地使 Spring 框架管理的任何物件支援 AOP。Spring  AOP 模組為基於Spring的應用程式中的物件提供了事務管理服務。通過使用 Spring AOP,不用依賴EJB元件,就可以將宣告性事務管理整合到應用程式中。

  Spring DAO:JDBC DAO抽象層提供了有意義的異常層次結構,可用該結構來管理異常處理和不同資料庫供應商丟擲的錯誤訊息。異常層次結構簡化了錯誤處理,並且極大地降低了需要編寫的異常程式碼數量(例如開啟和關閉連線)。SpringDAO的面向 JDBC 的異常遵從通用的 DAO 異常層次結構。

  Spring ORM:Spring 框架插入了若干個 ORM 框架,從而提供了 ORM的物件關係工具,其中包括JDO、Hibernate 和  iBatis SQL Map。所有這些都遵從 Spring 的通用事務和DAO異常層次結構。

  Spring Web 模組:Web 上下文模組建立在應用程式上下文模組之上,為基於Web的應用程式提供了上下文。所以,Spring 框架支援與 Jakarta Struts的整合。Web模組還簡化了處理多部分請求以及將請求引數繫結到域物件的工作。

  Spring MVC 框架:MVC 框架是一個全功能的構建 Web 應用程式的 MVC實現。通過策略介面,MVC框架變成為高度可配置的,MVC 容納了大量檢視技術,其中包括JSP、Velocity、Tiles、iText 和 POI。

  Spring 框架的功能可以用在任何 J2EE伺服器中,大多數功能也適用於不受管理的環境。Spring的核心要點是:支援不繫結到特定 J2EE服務的可重用業務和資料訪問物件。毫無疑問,這樣的物件可以在不同 J2EE 環境 (Web或EJB)、獨立應用程式、測試環境之間重用。

  共2頁: 1 [2]

  內容導航

  第 1 頁:Hibernate工作原理及用的理由(1) 第 2 頁:Hibernate工作原理及用的理由(2)

   IOC 和 AOP

  控制反轉模式(也稱作依賴性介入)的基本概念是:不建立物件,但是描述建立它們的方式。在程式碼中不直接與物件和服務連線,但在配置檔案中描述哪一個元件需要哪一項服務。容器(在Spring框架中是 IOC 容器) 負責將這些聯絡在一起。

  在典型的 IOC 場景中,容器建立了所有物件,並設定必要的屬性將它們連線在一起,決定什麼時間呼叫方法。下表列出了IOC的一個實現模式。

  Spring 框架的 IOC 容器採用型別 2 和型別3 實現。

  面向方面的程式設計

即AOP,是一種程式設計技術,它允許程式設計師對橫切關注點或橫切典型的職責分界線的行為(例如日誌和事務管理)進行模組化。

AOP的核心構造是方面,它將那些影響多個類的行為封裝到可重用的模組中。

  AOP 和IOC是補充性的技術,它們都運用模組化方式解決企業應用程式開發中的複雜問題。在典型的面向物件開發方式中,可能要將日誌記錄語句放在所有方法和Java類中才能實現日誌功能。在 AOP方式中,可以反過來將日誌服務模組化,並以宣告的方式將它們應用到需要日誌的元件上。當然,優勢就是Java類不需要知道日誌服務的存在,也不需要考慮相關的程式碼。所以,用 Spring  AOP 編寫的應用程式程式碼是鬆散耦合的。

  AOP 的功能完全整合到了 Spring 事務管理、日誌和其他各種特性的上下文中。

  IOC 容器

  Spring 設計的核心是 org.springframework.beans 包,它的設計目標是與JavaBean元件一起使用。這個包通常不是由使用者直接使用,而是由伺服器將其用作其他多數功能的底層中介。下一個最高階抽象是BeanFactory介面,它是工廠設計模式的實現,允許通過名稱建立和檢索物件。BeanFactory也可以管理物件之間的關係。

  BeanFactory 支援兩個物件模型。

  單態模型提供了具有特定名稱的物件的共享例項,可以在查詢時對其進行檢索。Singleton是預設的也是最常用的物件模型。對於無狀態服務物件很理想。

  原型模型確保每次檢索都會建立單獨的物件。在每個使用者都需要自己的物件時,原型模型最適合。

  bean 工廠的概念是 Spring 作為 IOC容器的基礎。IOC將處理事情的責任從應用程式程式碼轉移到框架。正如我將在下一個示例中演示的那樣,Spring 框架使用JavaBean屬性和配置資料來指出必須設定的依賴關係。

  BeanFactory 介面

  因為org.springframework.beans.factory.BeanFactory是一個簡單介面,所以可以針對各種底層儲存方法實現。最常用的BeanFactory 定義是 XmlBeanFactory,它根據XML 檔案中的定義裝入 bean,如清單 1 所示。

  清單 1. XmlBeanFactory

  BeanFactory factory = new XMLBeanFactory(newFileInputSteam("mybean.xml"));

  在 XML 檔案中定義的 Bean 是被消極載入的,這意味在需要 bean 之前,bean本身不會被初始化。要從BeanFactory檢索  bean,只需呼叫 getBean() 方法,傳入將要檢索的 bean的名稱即可,如清單 2所示。

  清單 2. getBean()

  MyBean mybean = (MyBean) factory.getBean("mybean");

  每個 bean 的定義都可以是 POJO (用類名和 JavaBean 初始化屬性定義)或FactoryBean。FactoryBean 介面為使用 Spring 框架構建的應用程式添加了一個間接的級別。

  IOC 示例

  理解控制反轉最簡單的方式就是看它的實際應用。在對由三部分組成的 Spring 系列 的第1部分進行總結時,我使用了一個示例,演示瞭如何通過 Spring IOC 容器注入應用程式的依賴關係(而不是將它們構建進來)。

  我用開啟線上信用帳戶的用例作為起點。對於該實現,開啟信用帳戶要求使用者與以下服務進行互動:

  信用級別評定服務,查詢使用者的信用歷史資訊。

  遠端資訊連結服務,插入客戶資訊,將客戶資訊與信用卡和銀行資訊連線起來,以進行自動借記(如果需要的話)。

  電子郵件服務,向用戶傳送有關信用卡狀態的電子郵件。

  三個介面

  對於這個示例,我假設服務已經存在,理想的情況是用鬆散耦合的方式把它們整合在一起。以下清單顯示了三個服務的應用程式介面。

  清單 3. CreditRatingInterface

Public interface CreditRatingInterface

 Public Boolean  getUserCreditHistoryInformation(ICustomer  iCustomer);

  清單 3 所示的信用級別評定介面提供了信用歷史資訊。它需要一個包含客戶資訊的  Customer物件。該介面的實現是由CreditRating 類提供的。

  清單 4. CreditLinkingInterface

  public interface CreditLinkingInterface

  public String getUrl(); public void setUrl(String url);publicvoid  linkCreditBankAccount() throws Exception ;

  信用連結介面將信用歷史資訊與銀行資訊(如果需要的話)連線在一起,並插入使用者的信用卡資訊。信用連結介面是一個遠端服務,它的查詢是通過getUrl()方法進行的。URL 由 Spring 框架的 bean 配置機制設定,我稍後會討論它。該介面的實現是由CreditLinking類提供的。

  清單 5. EmailInterface

  public interface EmailInterface

  public void sendEmail(ICustomer iCustomer);  publicStringgetFromEmail(); public void setFromEmail(String fromEmail)  ;publicString getPassword(); public void setPassword(Stringpassword) ;public  String getSmtpHost() ; public voidsetSmtpHost(StringsmtpHost); public String  getUserId() ; publicvoid setUserId(StringuserId);

原理:

1.        
讀取並解析配置檔案

2.         讀取並解析對映資訊,建立SessionFactory

3.         開啟Sesssion

4.         建立事務Transation

5.         持久化操作

6.         提交事務

7.         關閉Session

8.         關閉SesstionFactory


為什麼要用:


1.   
對JDBC訪問資料庫的程式碼做了封裝,大大簡化了資料訪問層繁瑣的重複性程式碼。

2.    Hibernate是一個基於JDBC的主流持久化框架,是一個優秀的ORM實現。他很大程度的簡化DAO層的編碼工作

3.   hibernate使用Java反射機制,而不是位元組碼增強程式來實現透明性。

4.    hibernate的效能非常好,因為它是個輕量級框架。對映的靈活性很出色。它支援各種關係資料庫,從一對一到多對多的各種複雜關係。


2. Hibernate是如何延遲載入?

1.         Hibernate2延遲載入實現:a)實體物件 b)集合(Collection)

2.         Hibernate3提供了屬性的延遲載入功能

當Hibernate在查詢資料的時候,資料並沒有存在與記憶體中,當程式真正對資料的操作時,物件才存在與記憶體中,就實現了延遲載入,他節省了伺服器的記憶體開銷,從而提高了伺服器的效能。

3. Hibernate中怎樣實現類之間的關係?(如:一對多、多對多的關係)

類與類之間的關係主要體現在表與表之間的關係進行操作,它們都市對物件進行操作,我們程式中把所有的表與類都對映在一起,它們通過配置檔案中的many-to-one、one-to-many、many-to-many、

4. 說下Hibernate的快取機制

1.         內部快取存在Hibernate中又叫一級快取,屬於應用事物級快取

2.         二級快取:

a)         應用及快取

b)        分散式快取


條件:資料不會被第三方修改、資料大小在可接受範圍、資料更新頻率低、同一資料被系統頻繁使用、非關鍵資料

c) 第三方快取的實現

5. Hibernate的查詢方式

Sql、Criteria,object comptosition

Hql:

1、 屬性查詢

2、 引數查詢、命名引數查詢

3、 關聯查詢

4、 分頁查詢

5、 統計函式


6. 如何優化Hibernate?

1.        
使用雙向一對多關聯,不使用單向一對多

2.        
靈活使用單向一對多關聯

3.         不用一對一,用多對一取代

4.         配置物件快取,不使用集合快取

5.         一對多集合使用Bag,多對多集合使用Set

6.         繼承類使用顯式多型

7.         表字段要少,表關聯不要怕多,有二級快取撐腰


7. Struts工作機制?為什麼要使用Struts?

工作機制:

Struts的工作流程:

在web應用啟動時就會載入初始化ActionServlet,ActionServlet

struts-config.xml檔案中讀取配置資訊,把它們存放到各種配置物件

當ActionServlet接收到一個客戶請求時,將執行如下流程.

    -(1)檢索和使用者請求匹配的ActionMapping例項,如果不存在,就返回請求路徑無效資訊;

    -(2)如果ActionForm例項不存在,就建立一個ActionForm物件,把客戶提交的表單資料儲存到ActionForm物件中;

    -(3)根據配置資訊決定是否需要表單驗證.如果需要驗證,就呼叫ActionForm的validate()方法;

    -(4)如果ActionForm的validate()方法返回null或返回一個不包含ActionMessage的ActionErrors物件,就表示表單驗證成功;

    -(5)ActionServlet根據ActionMapping所包含的對映資訊決定將請求轉發給哪個Action,如果相應的Action例項不存在,就先建立這個例項,然後呼叫Action的execute()方法;

   -(6)Action的execute()方法返回一個ActionForward物件,ActionServlet在把客戶請求轉發給ActionForward物件指向的JSP元件;
     
    -(7)ActionForward物件指向JSP元件生成動態網頁,返回給客戶;

為什麼要用:

JSP、Servlet、JavaBean技術的出現給我們構建了強大的企業應用系統提供可能。但用這些技術構建的系統非常的繁亂,所以在此之上,我們需要一個規則、一個把這些技術組織起來的規則,這就是框架,Struts便應運而生。

基於Struts開發的應用由3類元件構成:C控制器元件、M模型元件、V檢視元件

8. Struts的validate框架是如何驗證的?

在struts配置檔案中配置具體的錯誤提示,再在FormBean中的validate()方法具體呼叫。

9. 說下Struts的設計模式

MVC模式: web應用程式啟動時就會載入並初始化ActionServler。使用者提交表單時,一個配置好的ActionForm物件被建立,並被填入表單相應的資料,ActionServler根據Struts-config.xml檔案配置好的設定決定是否需要表單驗證,如果需要就呼叫ActionForm的Validate()驗證後選擇將請求傳送到哪個Action,如果Action不存在,ActionServlet會先建立這個物件,然後呼叫Action的execute()方法。Execute()從ActionForm物件中獲取資料,完成業務邏輯,返回一個ActionForward物件,ActionServlet再把客戶請求轉發給ActionForward物件指定的jsp元件,ActionForward物件指定的jsp生成動態的網頁,返回給客戶。

單例模式

Factory(工廠模式):定義一個基類===》實現基類方法(子類通過不同的方法)===》定義一個工廠類(生成子類例項)

===》開發人員呼叫基類方法

Proxy(代理模式)

10. spring工作機制及為什麼要用?

1.spring mvc將所有的請求都提交給DispatcherServlet,它會委託應用系統的其他模組負責對請求進行真正的處理工作。

2.DispatcherServlet查詢一個或多個HandlerMapping,找到處理請求的Controller.

3.DispatcherServlet請求提交到目標Controller

4.Controller進行業務邏輯處理後,會返回一個ModelAndView

5.dispatcher查詢一個或多個ViewResolver檢視解析器,找到ModelAndView物件指定的檢視物件

6.檢視物件負責渲染返回給客戶端。

為什麼用:

{AOP 讓開發人員可以建立非行為性的關注點,稱為橫切關注點,並將它們插入到應用程式程式碼中。使用 AOP 後,公共服務   (比 如日誌、永續性、事務等)就可以分解成方面並應用到域物件上,同時不會增加域物件的物件模型的複雜性。

  IOC 允許建立一個可以構造物件的應用環境,然後向這些物件傳遞它們的協作物件。正如單詞 倒置 所表明的,IOC 就像反過來的 JNDI。沒有使用一堆抽象工廠、服務定位器、單元素(singleton)和直接構造(straight construction),每一個物件都是用其協作物件構造的。因此是由容器管理協作物件(collaborator)。

Spring即使一個AOP框架,也是一IOC容器。 Spring 最好的地方是它有助於您替換物件。有了 Spring,只要用 JavaBean 屬性和配置檔案加入依賴性(協作物件)。然後可以很容易地在需要時替換具有類似介面的協作物件。}

Spring的工作原理

一、 IoC(Inversion of control): 控制反轉
1
IOC概念:控制權由物件本身轉向容器;由容器根據配置檔案去建立例項並建立各個例項之間的依賴關係核心:bean工廠;Spring中,bean工廠建立的各個例項稱作bean二、AOP(Aspect-Oriented Programming): 面向方面程式設計1代理的兩種方式:靜態代理:針對每個具體類分別編寫代理類;針對一個介面編寫一個代理類;動態代理:針對一個方面編寫一個InvocationHandler然後借用JDK反射包中的Proxy類為各種介面動態生成相應的代理類
2
 AOP的主要原理:動態代理

Spring
工作原理
        Spring 
已經用過一段時間了,感覺Spring是個很不錯的框架。內部最核心的就是IOC了,動態注入,讓一個物件的建立不用new了,可以自動的生產,這其實就是利用java裡的反射反射其實就是在執行時動態的去建立、呼叫物件,Spring就是在執行時,跟xml  Spring的配置檔案來動態的建立物件,和呼叫物件裡的方法的
     Spring
還有一個核心就是AOP這個就是面向切面程式設計,可以為某一類物件進行監督和控制(也就是在呼叫這類物件的具體方法的前後去呼叫你指定的模組)從而達到對一個模組擴充的功能。這些都是通過配置類達到的。
   Spring
目的:就是讓物件與物件(模組與模組)之間的關係沒有通過程式碼來關聯,都是通過配置類說明管理的(Spring根據這些配置內部通過反射去動態的組裝物件)要記住:Spring是一個容器,凡是在容器裡的物件才會有Spring所提供的這些服務和功能。
Spring
裡用的最經典的一個設計模式就是:模板方法模式。(這裡我都不介紹了,是一個很常用的設計模式)
  Spring
裡的配置是很多的,很難都記住,但是Spring裡的精華也無非就是以上的兩點,把以上兩點跟理解了也就基本上掌握了Spring.