spring 面試題

1. Spring工做機制 
(1) Spring mvc將全部的請求都提交給DispatcherServlet,它會委託應用系統的其餘模塊負責負責對請求進行真正的處理工做。 
(2) DispatcherServlet查詢一個或多個HandlerMapping,找處處理請求的Controller. 
(3) DispatcherServlet將請求提交到目標Controller 
(4) Controller進行業務邏輯處理後，會返回一個ModelAndView 
(5) DispathcherServlet查詢一個或多個ViewResolver視圖解析器,找到ModelAndView對象指定的視圖對象 
(6) 結果視圖對象負責渲染返回給客戶端。 
2. Spring爲何要用 
Spring既是一個AOP框架，也是一個IOC容器。 Spring 最好的地方是它有助於您替換對象。有了 Spring，只要用 JavaBean 屬性和配置文件加入依賴性（協做對象）。而後能夠很容易地在須要時替換具備相似接口的協做對象。

AOP 讓開發人員能夠建立非行爲性的關注點，稱爲橫切關注點，並將它們插入到應用程序代碼中。使用 AOP 後，公共服務  （好比日誌、持久性、事務等）就能夠分解成方面並應用到域對象上，同時不會增長域對象的對象模型的複雜性。  
IOC 容許建立一個能夠構造對象的應用環境，而後向這些對象傳遞它們的協做對象。正如單詞倒置所代表的，IOC就像反過來的 JNDI。沒有使用一堆抽象工廠、服務定位器、單元素（singleton）和直接構造（straight construction），每個對象都是用其協做對象構造的。所以是由容器管理協做對象（collaborator）。  

Spring框架是一個分層架構，由7個定義良好的模塊組成。Spring模塊構建在覈心容器之上，核心容器定義了建立、配置和管理 bean 的方式，組成 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 抽象層提供了有意義的異常層次結構，可用該結構來管理異常處理和不一樣數據庫供應商拋出的錯誤消息。異常層次結構簡化了錯誤處理，而且極大地下降了須要編寫的異常代碼數量（例如打開和關閉鏈接）。Spring DAO 的面向 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）、獨立應用程序、測試環境之間重用。 
3. IOC 和 AOP 
控制反轉模式（也稱做依賴性介入）的基本概念是：不建立對象，可是描述建立它們的方式。在代碼中不直接與對象和服務鏈接，但在配置文件中描述哪個組件須要哪一項服務。容器 （在 Spring 框架中是 IOC 容器） 負責將這些聯繫在一塊兒。 在典型的 IOC 場景中，容器建立了全部對象，並設置必要的屬性將它們鏈接在一塊兒，決定什麼時間調用方法。 
面向方面的編程，即 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(new FileInputSteam("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); 
public void linkCreditBankAccount() throws Exception ; 
}

  
信用連接接口將信用歷史信息與銀行信息（若是須要的話）鏈接在一塊兒，並插入用戶的信用卡信息。信用連接接口是一個遠程服務，它的查詢是經過 getUrl() 方法進行的。URL 由 Spring 框架的 bean 配置機制設置，我稍後會討論它。該接口的實現是由 CreditLinking 類提供的。 
清單 5. EmailInterface

  
public interface EmailInterface { 
public void sendEmail(ICustomer iCustomer); 
public String getFromEmail(); 
public void setFromEmail(String fromEmail) ; 
public String getPassword(); 
public void setPassword(String password) ; 
public String getSmtpHost() ; 
public void setSmtpHost(String smtpHost); 
public String getUserId() ; 
public void setUserId(String userId);

} 

如何創建你的架構，而且怎樣讓你的各個應用層保持一致？如何整合框架以便讓每一個層在以一種鬆散偶合的方式彼此做用而不用管低層的技術細節？這對咱們來講真是一種挑戰。 這裏討論一個整合框架的策略( 使用3 種受歡迎的開源框架) ：表示層咱們用Struts； 業務層咱們用Spring；而持久層則用Hibernate。你也能夠用其餘FrameWork替換隻要能獲得一樣的效果。  
應用程序的分層  
大部分的Web應用在職責上至少能被分紅4層。 這四層是：presentation（描述），persistence（持久），business（業務）和domain model（域模塊）。每一個層在處理程序上都應該有一項明確的責任, 而不該該在功能上與其它層混合，而且每一個層要與其它層分開的，但要給他們之間放一個通訊接口。 咱們就從介紹各個層開始，討論一下這些層應該提供什麼，不該該提供什麼。 
表示層(The Presentation Layer) 
  通常來說，一個典型的Web應用的的末端應該是表示層。 不少Java發者也理解Struts所提供的。 象業務邏輯之類的被打包org.apache.struts.Action， 所以，咱們很同意使用Struts這樣的框架。 
下面是Struts所負責的： 
* 管理用戶的請求,作出相應的響應。 
* 提供一個Controller ,委派調用業務邏輯和其它上層處理。 
* 處理異常，拋給Struts Action 
* 爲顯示提供一個模型 
* UI驗證。 
如下條款，不應在Struts顯示層的編碼中常常出現。 它們與顯示層無關的。 
* 直接的與數據庫通訊，例如JDBC調用。 
* 與你應用程序相關聯的業務邏輯以及校驗。 
* 事物管理。 
在表示層引入這些代碼，則會帶來高偶合和麻煩的維護。 
持久層(The Persistence Layer)  
典型的Web應用的另外一個末端是持久層。這裏一般是程序最容易失控的地方。開發者老是低估構建他們本身的持久框架的挑戰性。系統內部的持續層不但須要大量調 試時間，並且還常常缺乏功能使之變得難以控制，這是持久層的通病。 還好有幾個ORM開源框架很好的解決了這類問題。尤爲是Hibernate。 Hibernate爲java提供了OR持久化機制和查詢服務, 它還給已經熟悉SQL和JDBC API 的Java開發者一個學習橋樑，他們學習起來很方便。 Hibernate的持久對象是基於POJO和Java collections。此外，使用Hibernate並不妨礙你正在使用的IDE。 
請看下面的條目，你在持久層編碼中須要瞭解的。 
* 查詢對象的相關信息的語句。 Hibernate經過一個OO查詢語言（HQL）或者正則表達的API來完成查詢。 HQL很是相似於SQL-- 只是把SQL裏的table和columns用Object和它的fields代替。 你須要學習一些新的HQL語言； 無論怎樣，他們容易理解而文檔也作的很好。 HQL是一種對象查詢的天然語言，花很小的代價就能學習它。 
* 如何存儲，更新，刪除數據庫記錄。 
* 象Hibernate這類的高級ORM框架支持大部分主流數據庫，而且他們支持 Parent/child關係，事務處理，繼承和多態。 
業務層（The Business Layer） 
    一個典型Web應用的中間部分是業務層或者服務層。 從編碼的視角來看，這層是最容易被忽視的一層。 而咱們卻每每在UI層或持久層周圍看到這些業務處理的代碼，這實際上是不正確的，由於它致使了程序代碼的緊密偶合，這樣一來，隨着時間推移這些代碼很難維護。幸虧，針對這一問題有好幾種Frameworks存在。 最受歡迎的兩個框架是Spring和PicoContainer。 這些爲也被稱爲microcontainers，他們能讓你很好的把對象搭配起來。 這兩個框架都着手於‘依賴注射’(dependency injection)(還有咱們知道的‘控制反轉’Inversion of Control=IoC)這樣的簡單概念。 這篇文章將關注於Spring的注射（譯註：經過一個給定參數的Setter方法來構造Bean,有所不一樣於Factory）, Spring還提供了Setter Injection(type2)，Constructor Injection(type3)等方式供咱們選擇。 Spring把程序中所涉及到包含業務邏輯和Dao的Objects——例如transaction management handler（事務管理控制）、Object Factoris(對象工廠)、service objects（服務組件）——都經過XML來配置聯繫起來。 
後面咱們會舉個例子來揭示一下Spring 是怎樣運用這些概念。 
業務層所負責的以下： 
* 處理應用程序的 業務邏輯和業務校驗 
* 管理事物 
* 容許與其它層相互做用的接口 
* 管理業務層級別的對象的依賴。 
* 在顯示層和持久層之間增長了一個靈活的機制，使得他們不直接的聯繫在一塊兒。 
* 經過揭示 從顯示層到業務層之間的Context來獲得business services。 
* 管理程序的執行（從業務層到持久層）。 
域模塊層（The Domain Model Layer ）  
既然咱們致力於的是一個不是很複雜的Web的應用， 咱們須要一個對象集合，讓它在不一樣層之間移動的。 域模塊層由實際需求中的業務對象組成 好比, OrderLineItem , Product等等。 開發者在這層不用管那些DTOs，僅關注domain object便可。 例如，Hibernate容許你將數據庫中的信息存放入對象（domain objects），這樣你能夠在鏈接斷開的狀況下把這些數據顯示到UI層。 而那些對象也能夠返回給持續層，從而在數據庫裏更新。 並且，你沒必要把對象轉化成DTOs（這可能似的它在不一樣層之間的在傳輸過程當中丟失），這個模型使得Java開發者能很天然運用OO，而不須要附加的編碼。 
域對象層（Domain Object Layer） 
這層是編碼的着手點，咱們的編碼就從這層開始。 例子中Order與OrderItem 是一個One—To—Many的關係。下面就是Domain Object Layer的兩個對象： 
· com.meagle.bo.Order.java: 包含了一個Order的概要信息 
· com.meagle.bo.OrderLineItem.java: 包含了Order的詳細信息  
好好考慮怎你的package命名,這反應出了你是怎樣分層的。 例如 domain objects在程序中可能打包在com.meagle.bo內。 更詳細一點將打包在com. meagle.bo的子目錄下面。business logic應該從com.meagle.serice開始打包，而DAO 對象應該位於com.meagle.service.dao.hibernate。反應Forms和Actions的 持久對象（presentation classes） 應該分別放在 com.meagle.action和com.meagle.forms包。 準確的給包命名使得你的classes很好分割而且易於維護，而且在你添加新的classes時，能使得程序結構上保持上下一致。 
持久層的配置（Persistence Layer Configuration）  
創建Hibernate的持久層須要好幾個步驟。 第一步讓咱們把BO持久化。既然Hibernate是經過POJO工做的， 所以Order和 OrderLineItem對象須要給全部的fileds 加上getter,setter方法。 Hibernate經過XML文件來映射(OR)對象，如下兩個xml文件分別映射了Order 和OrderItem對象。（這裏有個叫XDoclet工具能夠自動生成你的XML影射文件） 
- Order.hbm.xml 
- OrderLineItem.hbm.xml  
你能夠在WebContent/WEB-INF/classes/com/meagle/bo目錄下找到這些xml文件。Hibernate的SessionFactory是用來告訴程序 應該與哪一個數據庫通訊，該使用哪一個鏈接池或使用了DataSource，應該加載哪些持久對象。而Session接口是用來完成Selecting，Saving，Delete和Updating這些操做。

業務層的配置（Business Layer Configuration） 
既然咱們已經有了domain objects，接下來咱們就要business service objects了，用他們來執行程序的logic,調用持久層，獲得UI層的requests,處理transactions，而且控制 exceptions。爲了將這些鏈接起來而且易於管理，咱們將使用面向方面的SpringFramework。 Spring 提供了 控制倒置（inversion of control 0==IoC)和注射依賴設置（setter dependency injection）這些方式（可供選擇），用XML文件將對象鏈接起來。 IoC是一個簡單概念（它容許一個對象在上層接受其餘對象的建立），用IoC這種方式讓你的對象從建立中釋放了出來，下降了偶合度。 
創建咱們的業務服務對象（Building Our Business Service Objects） 
Business Object中的Setter方法接受的是接口，這樣咱們能夠很鬆散的定義對象實現，而後注入。 在咱們的案例中，咱們將用一個business service object接收一個DAO,用它來控制domain objects的持久化。因爲在這個例子中使用了Hibernate，咱們能夠很方便的用其餘持久框架實現同時通知Spring 有新的DAO可使用了。 
在面向接口的編程中，你會明白 「注射依賴」模式是怎樣鬆散耦合你的業務邏輯和持久機制的：）。  
Spring 和Bean 的還有一點要注意的： bean能夠以用兩種方式創造。 這些都在單例模式（Sington）和原型模式（propotype）中定義了。 默認的方式是singleton,這意味着共享的實例將被束縛。 而原形模式是在Spring用到bean的時候容許新建實例的。當每一個用戶須要獲得他們本身Bean的Copy時，你應該僅使用prototype模式。 （更多的請參考設計模式中的單例模式和原形模式） 
提供一個服務定位器（Providing a Service Locator）  
既然咱們已經將咱們的Serices和DAO搭配起來了。咱們須要把咱們的Service顯示到其餘層。 這個一般是在Struts或者Swing這層裏編碼。一個簡單方法就是用服務定位器返回給Spring context 。固然，能夠經過直接調用Spring中的Bean來作。

4. 說說Spring AOP和IOC AOP是OOP的延續，是Aspect Oriented Programming的縮寫，意思是面向方面編程, AOP很是適合開發J2EE容器服務器. IOC就是Inversion of Control，控制反轉。在Java開發中，IoC意味着將你設計好的類交給系統去控制，而不是在你的類內部控制。這稱爲控制反轉。