假如我們在寫一個(gè)基于Spring的普通應(yīng)用程序，不管我們用了多么精妙的設(shè)計(jì)模式，進(jìn)行了如何巧妙的設(shè)計(jì)，我們必須在某個(gè)地方執(zhí)行這樣的代碼：
ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(
new String[] {"applicationContext.xml", "applicationContext-part2.xml"});
appContext.getBean("…");
也許這樣的代碼算不上丑陋，但是它無疑破壞了程序的純潔性和透明性。我們的應(yīng)用程序開始顯式地依賴SpringFramework，我們必須清楚地知道Spring的配置文件有哪幾個(gè)，每個(gè)配置文件的加入或修改源代碼，我們必須在某些代碼模塊里調(diào)用丑陋的getBean方法來創(chuàng)造對象。
但是所有的這些丑陋的事情似乎在我們的Web應(yīng)用程序里消失啦，所有的代碼都是那么干凈，只有簡單的get與set及接口之間的調(diào)用，我們不需要知道ApplicationContext，我們甚至不需要知道Spring。但是我們所有的對象卻又是通過Spring的ApplicationContext來創(chuàng)造的！
看上去似乎很神奇，但是假如我們稍微思考一下，就會發(fā)現(xiàn)這是一件合情合理又如此簡單的事情，呵呵，只有第一個(gè)想到這個(gè)方法的人才是偉大的。讓我們仔細(xì)想一下普通應(yīng)用程序和Web應(yīng)用程序的最大區(qū)別在哪里？
其實(shí)真正的區(qū)別只有一個(gè)，普通應(yīng)用程序是一個(gè)主動執(zhí)行的程序，而Web應(yīng)用程序卻是被動的組件。這意味著Web應(yīng)用程序無法自己主動去生成自己的線程去執(zhí)行某項(xiàng)任務(wù)，而必須借用Web容器中的一個(gè)線程。想象一下一個(gè)簡單的任務(wù)：我們想每隔一段時(shí)間執(zhí)行一個(gè)任務(wù)，比如說在Console里打印出一行文字。在我們的Web應(yīng)用程序里應(yīng)該怎么完成？在我不知道Servlet Listener或Spring里提供的Schedule之前（其實(shí)Spring就是利用Servlet Listner初始化Application Context時(shí)啟動schedule的），這么簡單的任務(wù)在一個(gè)Web應(yīng)用程序里竟然是不可想象。還記得我當(dāng)時(shí)采用的是最傻的做法：寫了一個(gè)單獨(dú)的應(yīng)用程序，在這應(yīng)用程序的main函數(shù)里啟動了timetask。
但是如果換一種角度來看，整個(gè)Web應(yīng)用程序生活在容器里也給我們帶來了額外的好處，當(dāng)我們讓出了對應(yīng)用程序的控制權(quán)之后，我們可以讓容器幫我們完成很多本來很難處理的事情。其實(shí)IOC容器的真正作用也在于此，當(dāng)我們把我們的對象創(chuàng)建工作移交給IOC容器之后，我們發(fā)現(xiàn)整個(gè)程序變得如此清晰，如此透明，對象之間的關(guān)聯(lián)、哪些類需要事務(wù)處理或AOP功能、哪些類要遠(yuǎn)程訪問，所有這些復(fù)雜的事情在我們的程序里都不見了，我們只看到了簡單的get和set。
也許廢話太多，但我覺得經(jīng)過這樣分析，其實(shí)ApplicationContext之謎已經(jīng)不再是謎了。真正的關(guān)鍵在于當(dāng)我們的Web應(yīng)用程序是被動的組件時(shí)，它除了可以錯(cuò)用容器的線程之外還可以錯(cuò)用其它一些東西。我們可以讓容器來幫我們創(chuàng)建ApplicationContext，然后把它放在某個(gè)地方，然后在需要使用時(shí)讓容器從這個(gè)地方把ApplicationContext讀出來，并執(zhí)行相應(yīng)的Controller就可以了。
這個(gè)"某個(gè)地方"就是ServletContext，而這個(gè)創(chuàng)建ApplicationContext的地方就是Servlet Listner，而取到ApplicationContext的地方是我們的DispatcherServlet。
仔細(xì)想一下，其實(shí)Web服務(wù)器并沒有什么了不起的地方，它只是一個(gè)Java程序，它只是會在啟動的時(shí)候去ClassLoad某些指定文件夾下的lib或classes，它會讀某個(gè)在WEB-INF下面一個(gè)叫做web.xml的配置文件，再做一些初始化工作。Servlet Listener就是這個(gè)初始化工作的重要一步，服務(wù)器會讀出web.xml里配置好的所有l(wèi)istner，然后調(diào)用每個(gè)Listner的contextInitialized方法（它還會去調(diào)每個(gè)Servlet的init方法，不過把初始化方法寫在Listner里才是天經(jīng)地義的）。哈哈，這也正是Spring MVC創(chuàng)建ApplicationContext的最好時(shí)機(jī)，當(dāng)我們在web.xml里配置好ContextLoaderListener的時(shí)候，Spring就完成了ApplicationContext的創(chuàng)建過程，如果有人想研究源代碼的話可以去看一下，不過這個(gè)創(chuàng)建過程并不象想象中的那么有趣，只是通過Class.forName和BeanUtils.instantiateClass創(chuàng)建出一個(gè)WebApplicationContext，然后再讀了一下IOC容器的配置文件。
接下來的一個(gè)問題是我們要把創(chuàng)建的ApplicationContext放在哪里？答案是ServletContext，其實(shí)沒必須對ServletContext進(jìn)行深究，它只是可以一個(gè)可以全局存放Web應(yīng)用程序的場所，我們只要想象成一個(gè)全局的HashMap就可以了，我們可以要把它put進(jìn)去，就可以在Servlet或其它地方把它get出來。
Web服務(wù)器還要干的一件事件當(dāng)然是在某個(gè)request到來時(shí)，它會啟動一個(gè)單獨(dú)的線程（這也是為何Webwork可以把Context放到ThreadLocal里的原因），根據(jù)web.xml里的配置和request的URI匹配去執(zhí)行相應(yīng)的Servlet。由于Servlet可以很輕松地讀到ServletContext，當(dāng)然也可以很輕松地讀到ApplicationContext啦。接下來的事情就比想象中要簡單啦，經(jīng)過一些準(zhǔn)備工作之后ApplicationContext中的URLMapping里配置好的某個(gè)Controller，執(zhí)行一下再rend某個(gè)view就可以了。其實(shí)struts或webwork2的執(zhí)行過程也是如此，所以MVC framwork分析透了其實(shí)真沒什么了不起，遠(yuǎn)比O/R Mapping或其它的framework簡單。雖然MVC的執(zhí)行過程如此簡單，但是我們還需要了解一些細(xì)節(jié)上的事件，所以讓我們下次來討論一下Spring MVC framework的執(zhí)行過程吧。
