寫在前面
在之前對Spring的學習和開發中，一直處於會用的狀態，對Spring以及它的核心IOC、DI和AOP一直處於非常淺的認識。之前一直想找時間好好理解一下Spring，可是拖延症並沒有讓我這麼做。不過，這次的課堂作業就是對Spring的理解，所以正好可以借這個機會查找相關資料來加深下對Spring的理解。
Spring簡介
Spring是一個開源框架，於2013年興起的一個輕量級的Java開發框架，主要針對javaBean的生命週期進行管理的輕量級容器。Spring發展到現在，Spring所代表的已經不僅僅是一個框架，而是一系列Spring框架的集合，更像是一個Spring家族，其中包括:
- Spring Framework —— Spring框架，包括了IoC, AOP, MVC以及Testing
- Spring Data —— 一個用於簡化數據庫訪問，並支持雲服務的開源框架
- Spring Security —— 基於Spring AOP和Servlet過濾器的安全框架 (我覺得這個框架太大了，我之後會學習Shiro)
- Spring Boot —— 微服務框架，爲基於Spring的開發提供更快的入門體驗
- …. —— 更多Spring家族的框架
7個核心模塊
Spring的7個核心模塊大部分都是一些概念性的東西，所以我從網上摘瞭如下內容，原文網址見參考資料第一條。
- 核心容器：核心容器提供 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。
IOC/DI
IOC：Inversion of Control 控制反轉，不是一種技術，而是一種思想。一個重要的面向對象編程的法則，它能指導我們如何設計出鬆耦合、更優良的程序。
我是這麼理解IOC的：在傳統開發中，每個對象在要使用其它對象的時候，通常是使用new的形式創建對象，創建對象是開發者主動去創建的，也可以說創建對象的控制權是在開發者的手裏，這樣就會使對象間的耦合度變的很高，這顯然不是一種好的開發方式。當然，在使用了Spring之後，創建對象的工作就交給Spring，將創建的對象存儲到Spring容器中，所有的對象都交給Spring所管理。比如，當一個類(A)中調用另一個類(B)，首先，這兩個類都會被記錄到Spring中，類A告訴Spring自己是什麼，我需要類B。然後，Spring會創建這兩個對象，在合適的時機將所創建的對象B交給對象A，並且將對象A交給其它需要對象A的對象。
所以IOC，控制反轉，就是說將創建對象的控制權由開發者自己轉移到像Spring這樣的第三方，由Spring來負責控制對象的生命週期和對象間的關係，是Spring的核心。開發者所創建的對象都由Spring所管理。。
DI：Dependency Injection 依賴注入，動態的向某個對象提供它所需要的其他對象，依賴是通過外部注入的方式來實現的，很好的實現瞭解耦。
IoC和DI由什麼關係呢？其實它們是同一個概念的不同角度描述，由於控制反轉概念比較含糊（可能只是理解爲容器控制對象這一個層面，很難讓人想到誰來維護對象關係），所以2004年大師級人物Martin Fowler又給出了一個新的名字：“依賴注入”，相對IoC 而言，“依賴注入”明確描述了“被注入對象依賴IoC容器配置依賴對象”。
AOP
當時學習Spring的時候，就被AOP搞的頭暈，而且之後也一直沒應用過AOP，到現在也沒能弄明白什麼是AOP，只記得它的中文翻譯爲：面向切片編程。以下摘自網絡的專業解釋:
在軟件業，AOP爲Aspect Oriented Programming的縮寫，意爲：面向切面編程，通過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術。AOP是OOP的延續，是軟件開發中的一個熱點，也是Spring框架中的一個重要內容，是函數式編程的一種衍生範型。利用AOP可以對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度降低，提高程序的可重用性，同時提高了開發的效率。
我是這麼理解AOP的：在實際開發中，我們或多或少都會使用到同樣的代碼，最low的解決方案是通過複製粘貼來實現，這樣的話，如果修改代碼，則需要將所有粘貼的代碼都進行修改，這顯然是不被提倡的。稍微高級一點，是將那一段相同的代碼封裝成一個方法供其它方法進行調用，這樣做能解決大部分場景的需求，但是難免會出現一些特殊情況，需要做到徹底的分離，這時就需要用到AOP了。下面舉一個簡單的例子：
比如，我們按照需求實現一個註冊功能，暫時只做了數據的基本校驗，然後，需求更改，需要驗證用戶輸入的用戶名是否存在。這時，我們不應用AOP這種思想的話，肯定會修改之前寫好的代碼。可以，這種做法沒問題，畢竟需求只是檢查下用戶名是否存在。可是，如果之後再次新增需求呢？如:發送驗證短信信息、發送驗證郵件、非法字符的過濾等等等等需求，這時如果依然採用之前的方法，就會使工作量變的很大。那麼，使用了AOP思想的話，就不需要修改原有代碼，我們只需要定義一個方法，不用在原有代碼上調用該方法，系統就會自動執行這個方法。
在Spring中，Spring的AOP代理由Spring的IoC容器負責生成、管理，其依賴關係也由IoC容器負責管理。因此，AOP代理可以直接使用容器中的其他Bean實例作爲目標，這種關係可由IoC容器的依賴注入提供。——摘自第五個參考資料
小結
這篇博客中，我只談了我的理解，沒有代碼的具體實現。之後，會慢慢補充相關的代碼實現。還有就是這些都是我主觀的理解，如有錯誤，還請您指正。
個人博客:https://www.howieli.cn 和個人CSDN博客: http://blog.csdn.net/howieli_1995。