這篇博客我們使用傳統方式（即不使用Spring）來實現一個添加用戶的實例，再同理使用Spring實現添加用戶的實例，對比學習IoC的概念，以及爲什麼使用IoC等等，最後，簡單總結。下面我們開始：
傳統方式：
客戶端：
public class Client {
public static void main(String[] args){
//由我們的應用程序負責服務（對象）定位，主動發起查找
UserManager userManager = new UserManagerImpl();
userManager.addUser("jiuqiyuliang", "123456");
}
}
業務邏輯層：
UserManager接口：添加用戶的方法
public interface UserManager {
public void addUser(String userName,String password);
}
UserManager實現
public class UserManagerImpl implements UserManager{
@Override
public void addUser(String userName, String password) {
//由我們的應用程序負責服務（對象）定位，主動發起查找
//UserDao userDao = new UserDao4MysqlImpl();
UserDao userDao = new UserDao4OracleImpl();
userDao.addUser(userName, password);
}
數據訪問層：
UserDao接口：添加用戶的方式
public interface UserDao {
public void addUser(String userName,String password);
}
UserDao兩種實現（Mysql和Oracle）：傳統方式使用配置文件，然後使用工廠來創建相應的對象（即我們經常說的配置文件+抽象工廠+反射，一會兒我們再看看Spring創建對象的方式）
public class UserDao4MysqlImpl implements UserDao{
@Override
public void addUser(String userName, String password) {
//打印訪問Mysql的相關信息
System.out.println("UserDao4MysqlImpl.addUser");
}
}
public class UserDao4OracleImpl implements UserDao{
@Override
public void addUser(String userName, String password) {
//打印訪問Oracle的相關信息
System.out.println("UserDao4OracleImpl.addUser");
}
運行效果圖：
看到上面的代碼，非常的熟悉，因爲我們平時經常使用。但是問題來了，在業務邏輯層的實現中，UserDao有多種不同的實現方式，例如Mysql和Oracle，UserManager要依賴於UserDao的具體實現。**並且對象是由我們自己負責創建的，我們主動的發起了一個查找，要依賴於一種數據庫的實現。此時我們的UserManager就和UserDao的具體實現緊緊的耦合在一起了。**我們再看客戶端，我們要使用UserManager，同業務邏輯層一樣，還得需要我們自己負責主動查找UserManager的具體實現。
我們可以發現：傳統方式，對象和對象之間發生嚴重的依賴關係，耦合度非常高而且依賴關係都寫死在了代碼裏，項目不易修改和維護，必須要改代碼。
下面我們使用Spring方式改造實例，實現同樣的功能，讓Spring管理我們的對象，看看Spring是怎麼創建對象和描述對象之間依賴關係的。
Spring方式：
客戶端：
public class Client {
public static void main(String[] args){
BeanFactory factory = new ClassPathXmlApplicationContext("applicationContext.xml");
//到IOC容器中獲取UserManager
UserManager userManager = (UserManager) factory.getBean("userManager");
//UserManager使用UserDao，在配置文件已經有依賴關係
userManager.addUser("jiuqiyuliang", "123456");
}
}
業務邏輯層：
UserManager實現：
public class UserManagerImpl implements UserManager{
private UserDao userDao;
//使用構造方式賦值
public UserManagerImpl(UserDao userDao) {
this.userDao = userDao;
}
@Override
public void addUser(String userName, String password) {
userDao.addUser(userName, password);
}
}
Spring的配置文件：
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.1.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-4.1.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-4.1.xsd">
<!-- 使用spring管理對象的創建，還有對象的依賴關係 -->
<bean id="userDao4Mysql" class="com.tgb.spring.dao.UserDao4MysqlImpl"/>
<bean id="userDao4Oracle" class="com.tgb.spring.dao.UserDao4OracleImpl"/>
<bean id="userManager" class="com.tgb.spring.manager.UserManagerImpl">
<!-- (1)userManager使用了userDao，Ioc是自動創建相應的UserDao實現，都是由容器管理-->
<!-- (2)在UserManager中提供構造函數，讓spring將UserDao實現注入（DI）過來 -->
<!-- (3)讓spring管理我們對象的創建和依賴關係，必須將依賴關係配置到spring的核心配置文件中 -->
<constructor-arg ref="userDao4Oracle"/>
</bean>
</beans>
對比傳統的實現方式，再看客戶端和UserManager，我們可以發現：通過IoC或DI，我們只需要通過簡單的配置，而無需任何代碼就可以指定UserManager中所需的UserDao的具體實現。UserManager只需利用容器注入的UserDao實例，完成自身的業務邏輯，而不用關心具體實現來自哪、由誰實現。換句話說：我們不再需要自己負責創建對象，管理對象生命週期以及維護對象的依賴關係，這些都有Spring替我們完成了。
傳統方式和Spring方式對比：
傳統方式：
決定使用哪一個具體實現是由應用程序負責的，在編譯階段就確定了。
Spring方式：
調用類只依賴接口，而不依賴具體的實現類，減少了耦合。控制權交給了容器，在運行期才由容器決定將具體的實現動態的“注入”到調用類的對象中。這也是使用IoC的根本原因。
現在我們對IoC有了基本認識，我們再理解一下IoC的概念。
IoC：
（Inversion of Control），控制反轉，用白話來講，就是由容器控制程序之間的關係，而非傳統實現中，由程序代碼直接控制。這也就是所謂“控制反轉”的概念所在：控制權由應用代碼中轉到了外部容器，控制權的轉移，就是所謂反轉。
IoC的優缺點
優點：
1、把對象的創建和依賴關係定義在了XML文件中，我們改變子類的實現變得異常簡單。
2、控制反轉減輕了對象之間的耦合度，減輕了對象之間的依賴關係，增加了系統的靈活性，可維護性，以及可移植性等等。
缺點：
1、生成對象的方式變複雜了（事實上操作還是挺簡單的），對於不習慣這種方式的人，會覺得有些彆扭和不直觀。
2、創建對象因爲使用了反射技術，在效率上有些損耗。但相對於IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某對象的生成對效率要求特別高。
總結
IoC使得面向對象的世界更加簡單，面向接口編程成爲了可能。