當然你經常需要使用O/R mapping，而不是使用關係數據訪問。你總體的應用程序框架也必須支持它。因而提供了對Hibernate 2.x和JDO的集成支持。它的數據訪問架構使得它能和任何底層的數據訪問技術集成。Spring和Hibernate集成得尤其好。
爲什麼你要使用Hibernate加Spring，而不是直接使用Hibernate？
Session 管理 Spring提供有效率的，簡單的以並且是安全的處理Hibernate Session。使用Hibernate的相關代碼爲了效率和恰當的事務處理一般需要使用相同的Hibernate “Session”對象。Spring讓它容易透明地創建和綁定Session到當前的線程，要麼使用聲明式，AOP的method interceptor方法，要麼在Java代碼層面使用顯式的，“template”包裝類。因而Spring解決了在Hibernate論壇上經常出現的用法問題。
資源管理 Spring的應用程序context能夠處理Hiberante SessionFactories的位置和配置，JDBC數據源和其他相關資源。這使得這些值易於管理和改變。
集成的事務管理 Spring讓你能夠把你的Hibernate代碼包裝起來，要麼使用聲明式，AOP風格的method interceptor，要麼在Java代碼層面顯式使用“template”包裝類。在兩種做法中，事務語義都爲你處理了，並且在異常時也做好了恰當的事務處理（回滾，等）。如下面討論的，你還獲得了能夠使用和替換不同transaction manager，而不會讓你相關Hibernate代碼受到影響的能力。額外的，JDBC相關的代碼能夠完全事務性的和Hibernate代碼集成。這對於處理沒有在Hibernate實現的功能很有用。
如上描述的異常包裝 Spring能夠包裝Hibernate異常，把它們從私有的，checked異常轉換爲一套抽象的運行時異常。這使得你能夠僅僅在恰當的層面處理大部分不可恢復的持久化異常，而不影響樣板catch/throw，和異常聲明。你仍然能夠在任何你需要的地方捕捉和處理異常。記住JDBC異常（包括DB特有的方言）也被轉換到相同的層次中，意味着你能在一致的編程模型中對JDBC執行相同的操作。
爲了避免和廠商綁定 Hibernate是強大的，靈活的，開放源代碼並且免費，但是它仍然使用私有的API。給出了一些選擇，使用標準或者抽象API實現主要的程序功能通常是你想要的，當你需要因爲功能，性能，或者其他考慮要轉換到使用其他實現時。
讓測試變簡單 Spring的Inversion of Control方法使得改變Hibernate的session factories，數據源，transaction manager的實現和位置很容易，如果需要的話還能改變mapper object的實現。這使得更加容易分離和測試持久化相關的代碼。
抽象出一個數據訪問的API是不夠的；我們還需要考慮事務管理。JTA是顯而易見的選擇，但是它是一個直接用起來很笨重的API，因而許多J2EE開發者感到EJB CMT是對於事務管理唯一合理的選擇。
Spring提供了它自己對事務管理的抽象。Spring提供了這些：
通過類似於JdbcTemplate的回調模板編程管理事務，比起直接使用JTA要容易多了
類似於EJB CMT的聲明式事務管理，但是不需要EJB容器
Spring的事務抽象式唯一的，它不綁定到JTA或者任何其他事務管理技術。Spring使用事務策略的概念把程序代碼和底層的事務架構（例如JDBC）解藕。
爲什麼你要關心這些？JTA不是所有事務管理的最好答案嗎？如果你正在編寫僅僅使用一個數據庫的程序，你不需要JTA的複雜度。你不關心XA事務或者兩階段提交。你甚至不需要提供這些東西的高端應用服務器。但是另一方面，你不會希望在需要和多個數據源打交道的時候重寫你的代碼。
假定你決定通過直接使用JDBC或者Hibernate的事務以避免JTA帶來的額外負擔。一旦你需要處理多個數據源，你必須剝開所有的事務管理代碼並且使用JTA事務來替代。這不是非常有吸引力的並且導致大部分J2EE程序員，包括我自己，推薦只使用全局JTA事務。然而使用Spring事務抽象，你只需要重新配置Spring讓它使用JTA，而不是JDBC或者Hibernate的事務策略，就一切OK了。這是一個配置上的改變，而不是代碼的改動。因而，Spring使得你能夠自由縮放應用。
AOP
最近在應用AOP來解決企業關注點方面大家有了很大的興趣，例如事務管理，這些都是EJB所要解決的。
Spring的AOP支持的首要目標是要給POJOs提供J2EE服務。這類似於JBoss 4的目標，Spring AOP由它能夠在應用服務器之間移植的優勢，因而沒有綁死在廠商身上的風險。它既可以在web或者EJB容器中使用，也能夠在WebLogic，Tomcat，JBoss，Resin，Jetty，Orion和許多其他應用服務器和web容器上使用。
Spring AOP支持method interception。所支持關鍵的AOP概念包括：
Interception：自定義行爲能夠在對接口和類的調用之前和之後插入。這類似於AspectJ術語中類似的“around advice”。
Introduction：指定advice會導致對象實現額外的接口。這混亂了繼承。
靜態和動態的pointcuts：在interception發生的程序執行處指定points。靜態pointcuts concern函數簽名；動態pointcuts也可以在point被求值的地方考慮函數的參數。Pointcuts獨立interceptors單獨定義，使得標準interceptor可以應用於不同應用程序和代碼上下文。
Spring既支持有狀態（一個advised對象一個實例）也支持無狀態的interceptors（所有advice使用一個實例）。
Spring不支持field interception。這是一個經過深思熟慮的設計決定。我總是感覺field interception違反了封裝。我比較傾向於把AOP作爲補全物，而不是與OOP衝突的東西。如果在5年或者10年後，我們在AOP學習曲線上走得更遠了並且覺得應該在程序設計的桌面上給AOP一個位置，我不會驚訝的。（然而在那個時候基於語言的解決方案例如AspectJ可能比它們今天看來更加具有吸引力。）
Spring使用動態代理實現AOP（其中存在一個接口）或者在運行時使用CGLIB生成字節碼（這使得能夠代理類）。兩種方法都能夠在任何應用服務器中使用。
Spring是第一個實現AOP Alliance interfaces的AOP 框架（www.sourceforge.net/projects/aopalliance）。這些是定義在不同AOP框架中能夠互操作interceptors的嘗試。
在TheServerSide和其他地方有一個正在進行但是不是那麼引人注目的爭論，就是這種interception是不是“true AOP”。我倒不怎麼在意它叫什麼；僅僅需要知道它是否在實踐中有用就好了。我也樂於稱它爲“declarative middleware”（聲明式中間件）。把Spring AOP認做簡單，輕量級的無狀態beans的替代物，這樣就不需要monolithic EJB容器了，而這些僅僅是讓你能夠構建有你需要的服務的容器。我不推薦advising任何一個POJO，對local SLSBs的類比有助於你理解推薦的粒度。（然而，與EJB不同的是，在恰當但是少見的情況下，你可以自由地把Spring的AOP應用到粒度更好的對象上。）
因爲Spring在實例上advises 對象，而不是在class loader層面上，使用有不同advice的同一個類的多個實例是可能的，或者與advised實例一道使用unadvised 實例。
可能Spring AOP最常見的應用是聲明式事務管理。這是基於前面描述的TansactionTemplate抽象上的，並且可以給任何POJO提供聲明式事務管理。取決於事務策略，底層的機制可以是JTA，JDBC，Hibernate或者任何其他提供事務管理的API。
Spring的聲明式事務管理類似於EJB CMT，在以下方面有些不同：
事務管理能夠應用於任何POJO。我們推薦業務對象實現接口，但是這只是一個好的編程習慣的問題，而不是由框架強制的。
通過使用Spring的事務API能夠在事務性POJO中實現編程回調。我們爲此提供靜態的方法，使用ThreadLoacal變量，因而你不需要傳播諸如EJBContext這樣的context對象來確保回滾。
你可以聲明式地定義“回滾規則”。EJB不會在未捕捉程序異常的時候自動回滾（僅僅在unchecked exceptions和其他Throwables的時候），應用程序開發者經常需要在任何異常發生時回滾。Spring事務管理讓你能夠聲明式地指定什麼異常什麼子類能夠導致自動回滾。缺省的行爲和EJB是一致的，但是你能夠在checked和unchecked異常時自動回滾。這個在最少化自編程回調代碼方面有很大好處，而回調依賴於Spring的事務API（因爲EJB的編程回調時在EJBContext中完成的）。
事務管理不綁定於JTA。如前面解釋過的，Spring的事務管理能夠在不同事務策略中使用。
當然還可以使用Spring AOP實現程序特有的aspects。取決於你對AOP概念的接受程度，決定你是否選擇這麼做，而不是Spring的能力，但是它確實非常有用。我們所見過的成功例子包括：
自定義的security interception，當安全檢查的複雜度超出了J2EE安全架構的能力的時候
在開發中使用的調試和profiling aspects
發送email通知管理員用戶不尋常的舉動的Interceptors
程序自定的aspects能夠成爲消除需要許多函數的樣板代碼的有利武器。
Spring AOP透明地與Spring BeanFactory概念集成。包含一個來自Spring BeanFactory對象地代碼不需要知道它是還是不是advised。和任何對象一樣，契約實在接口和對象實現中定義的。
下面的XML片斷展示瞭如何定義一個AOP代理：
| 代碼: |
<bean id="myTest" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="proxyInterfaces"> <value>org.springframework.beans.ITestBean</value> </property> <property name="interceptorNames"> <list> <value>txInterceptor</value> <value>target</value> </list> </property> </bean> |
注意bean類的定義總是AOP框架的ProxyFactoryBean，雖然bean的類型在引用中使用或者由BeanFactory的getBean()方法返回時依賴的是代理接口。（多個代理方法是被支持的。）ProxyFactoryBean的“interceptorNames”屬性需要一個字符串列表。（因爲如果代理是一個“prototype”而不是singleton，有狀態interceptors可能需要創建新的實例，所以必須使用Bean的名字而不是bean的引用。）列表中的名字可以是interceptor或者pointcuts（interceptors和有關它們合適被使用的信息）。列表中的“target”值自動創建一個“invoker interceptor”封裝target對象。實現代理接口的是在factory中的bean的名字。這個例子中的myTest可以和其他bean factory中的bean一樣使用。例如，其他對象可以使用<ref>元素引用它而且這些引用是由Spring IoC設置的。
還可以不用BeanFactory，編程構建AOP代理，雖然這個很少用得上：
| 代碼: |
TestBean target = new TestBean(); DebugInterceptor di = new DebugInterceptor(); MyInterceptor mi = new MyInterceptor(); ProxyFactory factory = new ProxyFactory(target); factory.addInterceptor(0, di); factory.addInterceptor(1, mi); // An "invoker interceptor" is automatically added to wrap the target ITestBean tb = (ITestBean) factory.getProxy(); |
我們相信最好把程序裝配從Java代碼中移出來，而AOP也不例外。
Spring在它的AOP能力方面的直接競爭者是Jon Tirsen的Nanning Aspects（http://nanning.codehaus.org）。
我覺得AOP作爲EJB的替代無提供企業服務這個用法方面的進步是重要的。隨着時間，這將成爲Spring很重要的關注點。
MVC web 框架
Spring包括一個強大而且高度可配置的MVC web 框架。
Spring的MVC model類似於Struts。在多線程服務對象這點上，Spring的Controller類似於Struts Action，只有一個實例處理所有客戶的請求。然而，我們相信Spring的MVC比起Struts有很多優點，例如：
Spring在controllers，JavaBean，models和views提供了一個非常清晰的劃分。
Spring的MVC是非常靈活的。不像Struts，它強制你的Action和Form對象進入固化的層次之中（因而你迫使你使用Java的實體繼承），Spring MVC完全是基於接口的。而且，通過插入你自己的接口幾乎Spring MVC 框架的所有部分都是可配置的。當然我們也提供了方便的類作爲實現選擇。
Spring MVC是真正的view無關的。你不會被強制使用JSP，如果你不想那麼做的話。你可以使用Velocity，XSLT或其他view技術。如果你想要使用自定義的view機制——例如，你自己的模板語言——你可以簡單實現Spring的View接口並且把它集成進來。
和其他對象一樣，Spring的Controllers是通過IoC配置的。着使得它們易於測試，並且完美地和其他由Spring管理的對象集成。
Web層變成了業務對象層之上的薄薄一層。這鼓勵了好的習慣。Struts和其他專門的web框架讓你去實現你自己的業務對象；Spring提供了你應用程序所有層的集成。
如在Struts 1.1中所見的，你可以有和你在Spring MVC 應用程序中所需要的一樣多的dispatcher servlets。
下面的例子展示了一個簡單的Spring Controller如何能夠訪問定義在應用程序context中的業務對象。這個controller在它的handleRequest()方法中執行了Google搜索：
| 代碼: |
public class GoogleSearchController implements Controller { private IGoogleSearchPort google; private String googleKey; public void setGoogle(IGoogleSearchPort google) { this.google = google; } public void setGoogleKey(String googleKey) { this.googleKey = googleKey; } public ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String query = request.getParameter("query"); GoogleSearchResult result = // Google property definitions omitted... // Use google business object google.doGoogleSearch(this.googleKey, query, start, maxResults, filter, restrict, safeSearch, lr, ie, oe); return new ModelAndView("googleResults", "result", result); } } |
這段代碼使用的prototype中，IGoogleSearchPort是一個GLUE web services代理，由Spring FActoryBean返回。然而，Spring把controller從底層web service庫中分離出來。接口可以使用普通的Java對象，test stub，mock對象或者如下面要討論的EJB代理實現。這個contorller不包括資源查找；除了支持它的web交互的必要代碼之外沒有別的什麼了。
Spring還提供了數據綁定，forms，wizards和更復雜的工作流的支持。
對Spring MVC 框架的優秀簡介是Thomas Risberg的Spring MVC 教程（http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html）。還可以參見“Web MVC with the Spring Framework”（http://www.springframework.org/docs/web_mvc.html）。
如果你樂於使用你鍾情的MVC框架，Spring的分層架構使得你能夠使用Spring的其他部分而不用MVC層。我們有使用Spring做中間層管理和數據訪問，但是在web層使用Struts，WebWork或者Tapestry的用戶。
MVC web 框架
Spring包括一個強大而且高度可配置的MVC web 框架。
Spring的MVC model類似於Struts。在多線程服務對象這點上，Spring的Controller類似於Struts Action，只有一個實例處理所有客戶的請求。然而，我們相信Spring的MVC比起Struts有很多優點，例如：
Spring在controllers，JavaBean，models和views提供了一個非常清晰的劃分。
Spring的MVC是非常靈活的。不像Struts，它強制你的Action和Form對象進入固化的層次之中（因而你迫使你使用Java的實體繼承），Spring MVC完全是基於接口的。而且，通過插入你自己的接口幾乎Spring MVC 框架的所有部分都是可配置的。當然我們也提供了方便的類作爲實現選擇。
Spring MVC是真正的view無關的。你不會被強制使用JSP，如果你不想那麼做的話。你可以使用Velocity，XSLT或其他view技術。如果你想要使用自定義的view機制——例如，你自己的模板語言——你可以簡單實現Spring的View接口並且把它集成進來。
和其他對象一樣，Spring的Controllers是通過IoC配置的。着使得它們易於測試，並且完美地和其他由Spring管理的對象集成。
Web層變成了業務對象層之上的薄薄一層。這鼓勵了好的習慣。Struts和其他專門的web框架讓你去實現你自己的業務對象；Spring提供了你應用程序所有層的集成。
如在Struts 1.1中所見的，你可以有和你在Spring MVC 應用程序中所需要的一樣多的dispatcher servlets。
下面的例子展示了一個簡單的Spring Controller如何能夠訪問定義在應用程序context中的業務對象。這個controller在它的handleRequest()方法中執行了Google搜索：
| 代碼: |
public class GoogleSearchController implements Controller { private IGoogleSearchPort google; private String googleKey; public void setGoogle(IGoogleSearchPort google) { this.google = google; } public void setGoogleKey(String googleKey) { this.googleKey = googleKey; } public ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String query = request.getParameter("query"); GoogleSearchResult result = // Google property definitions omitted... // Use google business object google.doGoogleSearch(this.googleKey, query, start, maxResults, filter, restrict, safeSearch, lr, ie, oe); return new ModelAndView("googleResults", "result", result); } } |
這段代碼使用的prototype中，IGoogleSearchPort是一個GLUE web services代理，由Spring FActoryBean返回。然而，Spring把controller從底層web service庫中分離出來。接口可以使用普通的Java對象，test stub，mock對象或者如下面要討論的EJB代理實現。這個contorller不包括資源查找；除了支持它的web交互的必要代碼之外沒有別的什麼了。
Spring還提供了數據綁定，forms，wizards和更復雜的工作流的支持。
對Spring MVC 框架的優秀簡介是Thomas Risberg的Spring MVC 教程（http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html）。還可以參見“Web MVC with the Spring Framework”（http://www.springframework.org/docs/web_mvc.html）。
如果你樂於使用你鍾情的MVC框架，Spring的分層架構使得你能夠使用Spring的其他部分而不用MVC層。我們有使用Spring做中間層管理和數據訪問，但是在web層使用Struts，WebWork或者Tapestry的用戶。
使用EJB
Spring還讓實現EJB變得更加容易。許多EJB程序使用Service Locator和Business Delegate模式。這些比在客戶代碼中遍佈JNDI查找強多了，但是它們常見的實現方式有顯著的缺點，例如：
使用EJB的典型代碼依賴Service Locator或者Business Delegate singletons，使得測試難於進行。
在Service Locator模式沒有使用Business Delegate的情況下，程序代碼還要在EJB home中調用create()方法，並且處理可能導致的異常。因而仍然綁定在EJB API身上，忍受着EJB 編程模型的複雜度。
實現Business Delegate模式通常導致顯著的代碼重複，其中我們必須編寫大量僅僅是調用EJB同等方法的方法。
基於這些和其他原因，傳統的EJB訪問，如在Sun Adventure Builder和OTN J2EE Virtual Shopping Mall中展示的那樣，會降低生產率並且帶來顯著的複雜度。
Spring通過引入codeless business delegate前進了一步。有了Spring，你不再需要再編寫另一個Service Locator，另一個JNDI查找，或者在硬編碼的Business Delegate中重複代碼，除非你肯定這增加了價值。
例如，假定我們有使用local EJB的web controller。我們將遵循最佳實踐，使用EJB Business Methods Interface模式，EJB的local interface extend非EJB專有的業務方法接口。（這麼做的主要的一個原因是確保在本地接口和bean實現類中方法簽名的自動同步。）讓我們調用這個業務方法接口MyComponent。當然我們還需要實現local home接口並且提供實現SessionBean和MyComponent業務方法的bean的實現類。
用了Spring EJB 訪問，我們把我們的web層controller和EJB實現掛接上所需要進行的Java編碼僅僅是在我們的controller中暴露一個類型MyComponent的setter方法。這將如下保存作爲實例變量的引用：
| 代碼: |
private MyComponent myComponent; public void setMyComponent(MyComponent myComponent) { this.myComponent = myComponent; } |
我們隨後在任何業務方法中使用這個實例變量。
Spring自動完稱剩下的工作，通過像這樣的XML bean定義。LocalStatelessSessionProxyFactoryBean是一個可以用於任何EJB的通用factory bean。它創建的對象能夠自動被Spring轉型爲MyComponent類型。
| 代碼: |
<bean id="myComponent" class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean"> <property name="jndiName"><value>myComponent</value></property> <property name="businessInterface"><value>com.mycom.MyComponent</value></property> </bean> <bean id="myController" class = "com.mycom.myController" > <property name="myComponent"><ref bean="myComponent"/></property> </bean> |
在幕後有許多魔法般的事情發生，Spring AOP framework的殷勤，雖然不強迫你使用AOP的概念享受這些結果。“myComponent”bean定義爲EJB創建一個代理，它實現了業務方法的接口。EJB local home在啓動的時候被緩存，因而只需要一次JNDI查找。每次EJB被調用的時候，代理調用local EJB中的create()方法並且調用EJB中對應的業務方法。
myController bean定義爲這個代理設置controller類的myController屬性。
這個EJB訪問機制極大簡化了應用程序的代碼：
Web層的代碼不依賴於EJB的使用。如果你想要使用POJO，mock object或者其他test stub替代EJB引用，我們可以簡單地改動一下myComponent bean定義而不影響一行Java代碼
我們還不需要寫一行JNDI查找或者其他EJB plumbing code。
在實際程序中的性能測試和經驗標明這種方法（包括對目標EJB的反射調用）的性能影響是很小的，在典型的應用中檢測不出。記住無論如何我們都不希望使用fine-grained的EJB調用，因爲會有有關應用服務器上的EJB的底層架構方面的代價。
我們可以把相同方法應用於遠程EJB，通過類似org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean factory bean的方法。然而我們無法隱藏遠程EJB的業務方法接口中的RemoteException。
測試
如你可能已經注意到的，我和其他Spring開發這是全面單元測試重要性的堅定支持者。我們相信框架被徹底單元測試過的是非常重要的，而且我們框架設計的主要目標是讓建立在框架之上的程序易於單元測試。
Spring自身有一個極好的單元測試包。我們的1.0 M1的單元測試覆蓋率是75%，而且我們希望在1.0 RC1的時候能夠達到80%的單元測試覆蓋率。我們發現在這個項目中測試優先的開發帶來的好處是實實在在的。例如，它使得作爲國際化分佈式開發團隊的工作極端有效率，而且用戶評論CVS snapshots趨向於穩定和使用安全。
因爲以下理由，我們相信用Spring構建的應用程序是非常易於測試的：
IoC推動了單元測試
應用程序不包括直接使用注入JNDI的J2EE服務的plumbing code，這些代碼一般讓測試難於進行
Spring bean factories和contexts能夠在容器外設置
在容器外可以設置Spring bean factory的能力提供了對開發過程有趣的可選項。在幾個使用Spring的web應用中，工作是從定義業務接口和在web容器外集成測試開始的。在業務功能已經足夠完整之後，web接口不過是添加在其上的薄薄一層。
誰在使用Spring
雖然相對來說Spring還是一個新的項目，但是我們已經有了一個令人印象深刻並且不斷增長的用戶羣。它們已經有許多產品使用着Spring。用戶包括一個主要的全球投資銀行（做大型項目的），一些知名的網絡公司，幾個web開發顧問機構，衛生保健公司，以及學院機構。
許多用戶完整地使用Spring，但是一些只單獨使用一些組件。例如，大量用戶使用我們地JDBC或者其他數據訪問功能。
Roadmap
在今年晚些時候我們主要要做的是讓Spring發佈release 1.0。然而，我們還有一些更長遠的目標。
爲1.0 final規劃地主要改進式源代碼級地元數據支持，它主要用於（但不侷限於）AOP框架。這將使得C#風格的attribute驅動的事務管理，並且讓聲明式企業服務在典型應用情況下非常容易配置。Attribute支持將會在Spring的1.0 final release支持中加入，並且設計的是在發佈的那個時候能與JSR-175集成。
1.0之後，一些可能的改進地方包括：
通過對我們的JDBC和事務支持的一個相當抽象來支持JMS
支持bean factories的動態重配置
提供web services的能力
IDE和其他工具支持
作爲一個敏捷項目，我們主要是受到用戶需求的驅動。因而我們不會開發沒有一個用戶需要的特性，並且我們會仔細傾聽來自用戶羣的聲音。
總結
Spring是一個解決了許多在J2EE開發中常見的問題的強大框架。
Spring提供了管理業務對象的一致方法並且鼓勵了注入對接口編程而不是對類編程的良好習慣。Spring的架構基礎是基於使用JavaBean屬性的Inversion of Control容器。然而，這僅僅是完整圖景中的一部分：Spring在使用IoC容器作爲構建完關注所有架構層的完整解決方案方面是獨一無二的。
Spring提供了唯一的數據訪問抽象，包括簡單和有效率的JDBC框架，極大的改進了效率並且減少了可能的錯誤。Spring的數據訪問架構還集成了Hibernate和其他O/R mapping解決方案。
Spring還提供了唯一的事務管理抽象，它能夠在各種底層事務管理技術，例如JTA或者JDBC紙上提供一個一致的編程模型。
Spring提供了一個用標準Java語言編寫的AOP框架，它給POJOs提供了聲明式的事務管理和其他企業事務——如果你需要——還能實現你自己的aspects。這個框架足夠強大，使得應用程序能夠拋開EJB的複雜性，同時享受着和傳統EJB相關的關鍵服務。
Spring還提供了可以和總體的IoC容器集成的強大而靈活的MVC web框架。