Spring的哲學是在不影響Java對象的設計的狀況下將Java對象加入到框架中。 咱們下面來看看Spring的工做原理,看看Spring是如何作到不影響Java對象的。
EJB的框架採用了一種侵略性(Invasive)的方法來設計對象,它要求你在設計中加入符合EJB規範的代碼。一些輕量級的COP框架,例如Avalon,也要求對象設計時必須符合某種規範,例如Serviceable接口,這種作法是典型的Type 1作法。
這 種設計思路要求Spring採用一種動態的、靈活的方式來設計框架。在Spring的工做原理中大量採用了反射。首先Spring要解決的一個問題就是如 何管理bean。由於IOC的思想要求bean之間不可以直接調用,而應該採用一種被動的方式進行協做。因此bean的管理是Spring工做原理中的核 心部分。
反射和內省在代碼的層次上思考問題,有時候可以帶來出人意料的靈活性。但它的使用有時候也是一個哲學問題,不管是在ORM設計仍是在AOP設計上都出現了相似的問題-到底是使用反射,仍是使用代碼生成。
在 Spring中,處理這個問題的核心是在org.springframework.beans包中。而其中最爲核心的部分,則是BeanWrapper。 BeanWrapper,顧名思義,就是bean的包裝器。因此,它的主要工做,就是對任何一個bean,進行屬性(包括內嵌屬性)的設置和方法的調用。 在
BeanWrapper的默認實現類BeanWrapperImpl中,雖然代碼較長,但完成的工做倒是很是的集中的。
BeanWrapper的深刻研究
咱們看看這個BeanWrapper是如何發揮運做的,假設咱們有兩個bean:java
public class Company { private String name; private Employee managingDirector; public String getName() { return this.name; } public void setName(String name) { this.name = name; } public Employee getManagingDirector() { return this.managingDirector; } public void setManagingDirector(Employee managingDirector) { this.managingDirector = managingDirector; } } public class Employee { private float salary; public float getSalary() { return salary; } public void setSalary(float salary) { this.salary = salary; } } 而後咱們使用BeanWrapper來調用這兩個bean:
Company c = new Company(); BeanWrapper bwComp = BeanWrapperImpl(c); // setting the company name... bwComp.setPropertyValue("name", "Some Company Inc."); // ... can also be done like this: PropertyValue v = new PropertyValue("name", "Some Company Inc."); bwComp.setPropertyValue(v); // ok, lets create the director and tie it to the company: Employee jim = new Employee(); BeanWrapper bwJim = BeanWrapperImpl(jim); bwJim.setPropertyValue("name", "Jim Stravinsky"); bwComp.setPropertyValue("managingDirector", jim); // retrieving the salary of the managingDirector through the company Float salary = (Float)bwComp.getPropertyValue("managingDirector.salary"); 看起來麻煩了許多,可是這樣Spring就可使用統一的方式來管理bean的屬性了。 Bean的製造工廠 有了對單個Bean的包裝,還須要對多個的bean進行管理。在spring 中,把bean歸入到一個核心庫中進行管理。bean的生產有兩種方法:一種是一個bean產生多個實例,一種是一個bean只產生一個實例。若是對設計 模式熟悉的話,咱們就會想到,前者能夠採用Prototype,後者能夠採用Singleton。 注意到,反射技術的使用使得咱們再也不像原始的工廠方法模式那樣建立對象。反射能夠很是靈活的根據類的名稱建立一個對象。因此spring只使用了Prototype和Singleton這兩個基本的模式。 Spring 正是這樣處理的,可是咱們但願用戶可以維護統一的接口,而不須要關心當前的bean究竟是Prototype產生的獨立的bean,仍是 Singleton產生的共享的bean。因此,在org.springframework.beans.factory包中的BeanFactory定 義了統一的getBean方法。 JDBC再封裝JDBC優雅的封裝了底層的數據庫,可是JDBC仍然存在諸多的不變。你須要編寫大量的 代碼來完成CRUD操做,並且,JDBC不管是遇到什麼樣的問題,都拋出一個SQLException,這種作法在異常使用上被稱爲不完備的信息。由於問 題多是很複雜的,也許是數據庫鏈接的問題,也許是併發控制的問題,也許只是SQL語句出錯。沒有理由用一個簡單的SQLException就搞定所有的 問題了,這種作法有些不負責任。針對這兩個問題,Spring Framework提出了兩種解決方法:首先,提供一個框架,把JDBC應用中的獲取鏈接、異常處理、釋放等比較通用的操做所有都集中起來,用戶只須要提 供特定的實現就OK了。實現的具體細節採用的是模板方法。舉個例子,在org.springframework.jdbc.object包 中,MappingSqlQuery類實現了將SQL查詢映射爲具體的業務對象。JavaDoc中這樣寫到:Reusable query in which concrete subclasses must implement the abstract mapRow(ResultSet, int) method to convert each row of the JDBC ResultSet into an object. 用戶必須實現mapRow方法,這是典型模板方法的應用。咱們拿一個具體的例子來看看:
class UserQuery extends MappingSqlQuery { public UserQuery(DataSource datasource) { super(datasource, "SELECT * FROM PUB_USER_ADDRESS WHERE USER_ID = ?"); declareParameter(new SqlParameter(Types.NUMERIC)); compile(); } // Map a result set row to a Java object protected Object mapRow(ResultSet rs, int rownum) throws SQLException { User user = new User(); user.setId(rs.getLong("USER_ID")); user.setForename(rs.getString("FORENAME")); return user; } public User findUser(long id) { // Use superclass convenience method to provide strong typing return (User) findObject(id); } }
其次是第二個問題,最麻煩的地方應該說是須要截住JDBC的異常,而後判斷異常的類型,並從新拋出異常。錯誤的問題能夠經過鏈接來獲取,因此麻煩的是如何 截獲異常。Spring 框架採用的方法是回調,處理回調的類在Spring Framework中被稱爲template 。spring
JdbcTemplate template = new JdbcTemplate(dataSource); final List names = new LinkedList(); template.query("SELECT USER.NAME FROM USER", new RowCallbackHandler() { public void proce***ow(ResultSet rs) throws SQLException { names.add(rs.getString(1)); } });
回調函數是一個匿名類,其中也使用了模板方法,異常的處理都在父類中完成了。
層間鬆耦合
在 開放源碼界已經出現了大量的基於MVC的Web容器,可是這些容器都僅限於Web的範圍 ,不涉及Web層次後端的鏈接,Spring做爲一個總體性的框架,定義了一種Web層和後端業務層的鏈接方式, 這個思路仍然疏運圖MVC的範疇,但耦合更鬆散,不依賴於具體的集成層次。數據庫
public class GoogleSearchController implements Controller { private IGoogleSearchPort google; private String googleKey; public void setGoogle(IGoogleSearchPort google) { this.google = google; } public void setGoogleKey(String googleKey) { this.googleKey = googleKey; } public ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String query = request.getParameter("query"); GoogleSearchResult result = // Google property definitions omitted... // Use google business object google.doGoogleSearch(this.googleKey, query,start, maxResults, filter, r estrict, safeSearch, lr, ie, oe); return new ModelAndView("googleResults", "result", result); } }
回調函數是一個匿名類,其中也使用了模板方法,異常的處理都在父類中完成了。
後端