最近在作項目時牽扯到有關父子上下文的概念。程序員
何爲父子上下文呢?web
父上下文:spring
使用listener監聽器來加載配置文件,以下:編程
<listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener>
Spring 會建立一個WebApplicationContext上下文,稱爲父上下文(父容器),保存在 ServletContext中,key是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE的值。mvc
能夠使用Spring提供的工具類取出上下文對象:WebApplicationContextUtils.getWebApplicationContext(ServletContext);app
子上下文:jsp
使用Spring MVC 來處理攔截相關的請求時,會配置DispatchServlet:工具
<servlet> <servlet-name>dispatcherServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet </servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcherServlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>
每一個DispatchServlet會有一個本身的上下文,稱爲子上下文,它也保存在 ServletContext中,key 是"org.springframework.web.servlet.FrameworkServlet.CONTEXT"+Servlet名稱。當一 個Request對象產生時,會把這個子上下文對象(WebApplicationContext)保存在Request對象中,key是 DispatcherServlet.class.getName() + ".CONTEXT"。url
能夠使用工具類取出上下文對象:RequestContextUtils.getWebApplicationContext(request);spa
父上下文(父容器)和子上下文(子容器)的訪問權限:
子上下文能夠訪問父上下文中的bean,可是父上下文不能夠訪問子上下文中的bean。
父上下文使用與否
方案一,傳統型:
父上下文容器中保存數據源、服務層、DAO層、事務的Bean。
子上下文容器中保存Mvc相關的Action的Bean.
事務控制在服務層。
因爲父上下文容器不能訪問子上下文容器中內容,事務的Bean在父上下文容器中,沒法訪問子上下文容器中內容,就沒法對子上下文容器中Action進行AOP(事務)。
固然,作爲「傳統型」方案,也沒有必要這要作。
方案二,激進型:
Java世界的「面向接口編程」的思想是正確的,但在增刪改查爲主業務的系統裏,Dao層接口,Dao層實現類,Service層接口,Service層實現類,Action父類,Action。再加上衆多的O(vo\po\bo)和jsp頁面。寫一個小功能 七、8個類就寫出來了。 開發者說我就是想接點私活兒,和PHP,ASP搶搶飯碗,但我又是Java程序員。最好的結果是大項目能作好,小項目能作快。因此「激進型」方案就出現了-----沒有接口、沒有Service層、還能夠沒有衆多的O(vo\po\bo)。那沒有Service層事務控制在哪一層?只好上升的Action層。
本文不想說這是否是正確的思想,我想說的是Spring不會限制你這樣作。
因爲有了父子上下文,你將沒法實現這一目標。解決方案是只使用子上下文容器,不要父上下文容器 。因此數據源、服務層、DAO層、事務的Bean、Action的Bean都放在子上下文容器中。就能夠實現了,事務(註解事務)就正常工做了。這樣纔夠激進。
總結:不使用listener監聽器來加載spring的配置文件,只使用DispatcherServlet來加載spring的配置,不要父子上下文,只使用一個DispatcherServlet,事情就簡單了,什麼麻煩事兒也沒有了。
Java--大項目能作好--按傳統方式作,規規矩矩的作,好擴展,好維護。
Java--小項目能作快--按激進方式作,一週時間就能夠出一個版本,先上線接受市場(用戶)的反饋,再改進,再反饋,時間就是生命(成本)。