spring、spring mvc以及IOC的閱讀

時間 2019-11-11

標籤 spring mvc 以及 ioc 閱讀欄目 Spring 简体版

原文原文鏈接

spring vs spring-mvc

spring是應用級框架
spring mvc只是一個mvc框架
spring如今包含不少子模塊，咱們用的最多的是依賴注入。
spring模塊可分爲如下：
- Core Container:
- Data Access/Integration:
- Web:
- 其餘，如AOP、Aspects、Test等:
spring模塊框架以下：

使用Spring框架的優勢

像開發POJO類同樣去開發企業應用程序
模塊化管理
集成多種技術如ORM、logging、Quartz、JDK timers等
方便測試

使用Spring框架的缺點

第1、軟件系統中因爲引入了第三方IOC容器，生成對象的步驟變得有些複雜，原本是二者之間的事情，又憑空多出一道- 手續，因此，咱們在剛開始使用IOC框架的時候，會感受系統變得不太直觀。
第2、因爲IOC容器生成對象是經過反射方式，在運行效率上有必定的損耗。若是你要追求運行效率的話，就必須對此進行權衡，如WEB2.0。
第3、具體到IOC框架產品(好比：Spring)來說，須要進行大量的配製工做，比較繁瑣，對於一些小的項目而言，客觀上也可能加大一些工做成本
第4、IOC框架產品自己的成熟度須要進行評估，若是引入一個不成熟的IOC框架產品，那麼會影響到整個項目，因此這也是一個隱性的風險。

Spring IoC

1.兩種容器：

Spring BeanFactory Container
Spring ApplicationContext Container
ApplicationContext container包含了BeanFactory container的所有功能，在企業級應用中首推ApplicationContext容器；
可是在輕量級應用如移動設備和applet小程序中，BeanFactory仍有用武之地。

2.Metadata配置

XML based configuration file
Annotation-based configuration
Java-based configuration

Spring IoC容器做用

IOC理論提出的觀點大致是這樣的：藉助於「第三方」實現具備依賴關係的對象之間的解耦。
因爲引進了中間位置的「第三方」，也就是IOC容器，使得A、B、C、D這4個對象沒有了耦合關係，齒輪之間的傳動所有依靠「第三方」了，所有對象的控制權所有上繳給「第三方」IOC容器，因此，IOC容器成了整個系統的關鍵核心，它起到了一種相似「粘合劑」的做用，把系統中的全部對象粘合在一塊兒發揮做用，若是沒有這個「粘合劑」，對象與對象之間會彼此失去聯繫，這就是有人把IOC容器比喻成「粘合劑」的由來。html

圖1：軟件系統中耦合的對象web

圖3：IOC解耦過程spring

圖4：拿掉IoC容器後的系統小程序

IOC名稱的由來

控制反轉(IOC)到底爲何要起這麼個名字？咱們來對比一下：spring-mvc

軟件系統在沒有引入IOC容器以前，如圖1所示，對象A依賴於對象B，那麼對象A在初始化或者運行到某一點的時候，本身必須主動去建立對象B或者使用已經建立的對象B。不管是建立仍是使用對象B，控制權都在本身手上。mvc

軟件系統在引入IOC容器以後，這種情形就徹底改變了，如圖3所示，因爲IOC容器的加入，對象A與對象B之間失去了直接聯繫，因此，當對象A運行到須要對象B的時候，IOC容器會主動建立一個對象B注入到對象A須要的地方。app

經過先後的對比，咱們不難看出來：對象A得到依賴對象B的過程,由主動行爲變爲了被動行爲，控制權顛倒過來了，這就是「控制反轉」這個名稱的由來。框架

IOC的別名：依賴注入(DI)

2004年，Martin Fowler探討了同一個問題，既然IOC是控制反轉，那麼究竟是「哪些方面的控制被反轉了呢？」，通過詳細地分析和論證後，他得出了答案：「得到依賴對象的過程被反轉了」。控制被反轉以後，得到依賴對象的過程由自身管理變爲了由IOC容器主動注入。因而，他給「控制反轉」取了一個更合適的名字叫作「依賴注入（Dependency Injection）」。他的這個答案，實際上給出了實現IOC的方法：注入。所謂依賴注入，就是由IOC容器在運行期間，動態地將某種依賴關係注入到對象之中。ide

因此，依賴注入(DI)和控制反轉(IOC)是從不一樣的角度的描述的同一件事情，就是指經過引入IOC容器，利用依賴關係注入的方式，實現對象之間的解耦。模塊化