作為一名 Java 開發(fā)，對 Spring 框架是再熟悉不過的了。Spring 支持的控制反轉(zhuǎn)（Inversion of Control，縮寫為IoC）和面向切面編程（Aspect-oriented programming，縮寫為AOP）早已成為我們的開發(fā)習慣，仿佛 Java 開發(fā)天生就該如此。人總是會忽略習以為常的事物，所有人都熟練使用 IoC 和 AOP，卻鮮有人說得清楚到底為什么要用 IoC 和 AOP。

技術(shù)肯定是為了解決某個問題而誕生，要弄清楚為什么使用 IoC 和 AOP，就得先弄清楚不用它們會碰到什么問題。

IoC

我們現(xiàn)在假設(shè)回到了沒有 IoC 的時代，用傳統(tǒng)的 Servlet 進行開發(fā)。

傳統(tǒng)開發(fā)模式的弊端

三層架構(gòu)是經(jīng)典的開發(fā)模式，我們一般將視圖控制、業(yè)務(wù)邏輯和數(shù)據(jù)庫操作分別抽離出來單獨形成一個類，這樣各個職責就非常清晰且易于復(fù)用和維護。大致代碼如下：

@WebServlet("/user")
public class UserServlet extends HttpServlet {
    // 用于執(zhí)行業(yè)務(wù)邏輯的對象
    private UserService userService = new UserServiceImpl();
    
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        // ...省略其他代碼
            
        // 執(zhí)行業(yè)務(wù)邏輯
        userService.doService();
        
        // ...返回頁面視圖
    }
}

public class UserServiceImpl implements UserService{
    // 用于操作數(shù)據(jù)庫的對象
    private UserDao userDao = new UserDaoImpl();
    
    @Override
    public void doService() {
        // ...省略業(yè)務(wù)邏輯代碼
            
        // 執(zhí)行數(shù)據(jù)庫操作
        userDao.doUpdate();
        
        // ...省略業(yè)務(wù)邏輯代碼
    }
}

public class UserDaoImpl implements UserDao{
    @Override
    public void doUpdate() {
        // ...省略JDBC代碼
    }
}

上層依賴下層的抽象，代碼就分為了三層：

業(yè)界普遍按這種分層方式組織代碼，其核心思想是職責分離。層次越低復(fù)用程度越高，比如一個 DAO 對象往往會被多個 Service 對象使用，一個 Service 對象往往也會被多個 Controller 對象使用：

條理分明，井然有序。這些被復(fù)用的對象就像一個個的組件，供多方使用。

雖然這個倒三角看上去非常漂亮，然而我們目前的代碼有一個比較大的問題，那就是我們只做到了邏輯復(fù)用，并沒有做到資源復(fù)用。

上層調(diào)用下一層時，必然會持有下一層的對象引用，即成員變量。目前我們每一個成員變量都會實例化一個對象，如下圖所示：

每一個鏈路都創(chuàng)建了同樣的對象，造成了極大的資源浪費。本應(yīng)多個 Controller 復(fù)用同一個 Service，多個 Service 復(fù)用同一個 DAO?，F(xiàn)在變成了一個 Controller創(chuàng)建多個重復(fù)的 Service，多個 Service 又創(chuàng)建了多個重復(fù)的 DAO，從倒三角變成了正三角。

許多組件只需要實例化一個對象就夠了，創(chuàng)建多個沒有任何意義。針對對象重復(fù)創(chuàng)建的問題，我們自然而然想到了單例模式。只要編寫類時都將其寫為單例，這樣就避免了資源浪費。但是，引入設(shè)計模式必然會帶來復(fù)雜性，況且還是每一個類都為單例，每一個類都會有相似的代碼，其弊端不言自明。

有人可能會說，那我不在意“這點”資源浪費了，我服務(wù)器內(nèi)存大無所謂，我只求開發(fā)便捷痛快不想寫額外的代碼。

確實，三層架構(gòu)達到邏輯復(fù)用已經(jīng)非常方便了，還奢求其他的干什么呢。但就算不管資源問題，目前代碼還有一個致命缺陷，那就是變化的代價太大。

假設(shè)有 10 個 Controller 依賴了 UserService，最開始實例化的是 UserServiceImpl，后面需要換一個實現(xiàn)類 OtherUserServiceImpl，我就得逐個修改那 10 個 Controller，非常麻煩。更換實現(xiàn)類的需求可能不會太多，沒多大說服力。那咱們看另一個情況。

之前咱們演示的組件創(chuàng)建過程非常簡單，new 一下就完了，可很多時候創(chuàng)建一個組件沒那么容易。比如 DAO 對象要依賴一個這樣的數(shù)據(jù)源組件：

public class UserDaoImpl implements UserDao{
    private MyDataSource dataSource;

    public UserDaoImpl() {
        // 構(gòu)造數(shù)據(jù)源
        dataSource = new MyDataSource("jdbc:mysql://localhost:3306/test", "root", "password");
        // 進行一些其他配置
        dataSource.setInitiaSize(10);
        dataSource.setMaxActive(100);
        // ...省略更多配置項
    }
}

該數(shù)據(jù)源組件要想真正生效需要對其進行許多配置，這個創(chuàng)建和配置過程是非常麻煩的。而且配置可能會隨著業(yè)務(wù)需求的變化經(jīng)常更改，這時候你就需要修改每一個依賴該組件的地方，牽一發(fā)而動全身。這還只是演示了一個數(shù)據(jù)源的創(chuàng)建配置過程，真實開發(fā)中可有太多組件和太多配置需要編碼了，其麻煩程度堪稱恐怖。

當然，這些問題都可以引入設(shè)計模式來解決，不過這樣一來又繞回去了：設(shè)計模式本身也會帶來復(fù)雜性。這就像一種死循環(huán)：傳統(tǒng)開發(fā)模式編碼復(fù)雜，要想解決這種復(fù)雜卻得陷入另一種復(fù)雜。難道沒有辦法解決了嗎？當然不是的，在講優(yōu)秀解決方案前，我們先來梳理一下目前出現(xiàn)的問題：

• 創(chuàng)建了許多重復(fù)對象，造成大量資源浪費；
• 更換實現(xiàn)類需要改動多個地方；
• 創(chuàng)建和配置組件工作繁雜，給組件調(diào)用方帶來極大不便。

控制反轉(zhuǎn)和依賴注入

@Component
public class UserServiceImpl implements UserService{
    @Autowired // 獲取 Bean
    private UserDao userDao;
}

public class UserServiceImpl implements UserService{
    ...
}

// 將該實現(xiàn)類聲明為 Bean
@Component
public class OtherUserServiceImpl implements UserService{
    ...
}

AOP

面向?qū)ο蟮木窒扌?/span>

public class UserServiceImpl implements UserService {
    @Override
    public void doService() {
        System.out.println("---安全校驗---");
        System.out.println("---性能統(tǒng)計 Start---");
        System.out.println("---日志打印 Start---");
        System.out.println("---事務(wù)管理 Start---");

        System.out.println("業(yè)務(wù)邏輯");

        System.out.println("---事務(wù)管理 End---");
        System.out.println("---日志打印 End---");
        System.out.println("---性能統(tǒng)計 End---");
    }
}

面向切面編程

@Aspect // 聲明一個切面
@Component
public class MyAspect {
    // 原業(yè)務(wù)方法執(zhí)行前
    @Before("execution(public void com.rudecrab.test.service.*.doService())")
    public void methodBefore() {
        System.out.println("===AspectJ 方法執(zhí)行前===");
    }

    // 原業(yè)務(wù)方法執(zhí)行后
    @AfterReturning("execution(* com.rudecrab.test.service..doService(..))")
    public void methodAddAfterReturning() {
        System.out.println("===AspectJ 方法執(zhí)行后===");
    }
}

總結(jié)

• 創(chuàng)建了許多重復(fù)對象，造成大量資源浪費；
• 更換實現(xiàn)類需要改動多個地方；
• 創(chuàng)建和配置組件工作繁雜，給組件調(diào)用方帶來極大不便。

• 切面邏輯編寫繁瑣，有多少個業(yè)務(wù)方法就需要編寫多少次。