hibernate的分布式緩存
1、TreeCache / JBossCache
JBossCache是一個復制的事務處理緩存，它允許你緩存企業級應用數據來更好的改善性能。緩存數據被自動復制，讓你輕松進行JBoss伺服器之間 的集群工作。JBossCache能夠通過JBoss應用服務或其他J2EE容器來運行一個MBean服務，當然，它也能獨立運行。
2、WhirlyCache
Whirlycache是一個快速的、可配置的、存在於內存中的對象的緩存。它能夠通過緩存對象來加快網站或應用程序的速度，否則就必須通過查詢資料庫或其他代價較高的處理程序來建立。
3、SwarmCache
SwarmCache是一個簡單且有效的分布式緩存，它使用IP multicast與同一個區域網的其他主機進行通訊，是特別為集群和數據驅動web應用程序而設計的。SwarmCache能夠讓典型的讀操作大大超過寫操作的這類應用提供更好的性能支持。
4、JCache
JCache是個開源程序，正在努力成為JSR-107開源規范，JSR-107規范已經很多年沒改變了。這個版本仍然是構建在最初的功能定義上。
5、ShiftOne
ShiftOne Java Object Cache是一個執行一系列嚴格的對象緩存策略的Java lib，就像一個輕量級的配置緩存工作狀態的框架。
⑵ Hibernate中Session什麼意思
Hibernate中Session 是Hibernate中的緩存對象 用此session操作資料庫後會緩存返回的結果在session裡面 當你再次操作資料庫的時候 如果session緩存裡面有相應的值 則不用去與資料庫交互直接返回結果
servlet 中的Session 也是緩存 其緩存你與伺服器對話時候的一些信息
總之所有的session基本都是起緩存作用的 就是把一些信息緩存在內存中 方便存取值
但是不同的session是不能相互直接賦值的 因為是兩個不同的概念 只是名字一樣
名字一樣也是為了幫助程序員理解 學了servlet的session 後再遇到session也就應該是緩存作用的
不知道我的回答你滿意不
⑶ hibernate二級緩存什麼時候用
Hibernate緩存何時使用和如何使用？
Hibernate緩存分為二級，第一級存放於session中稱為一級緩存，默認帶有且不能卸載。第二級是由sessionFactory控制的進程級緩存。是全局共享的緩存，凡是會調用二級緩存的查詢方法 都會從中受益。
1. 關於hibernate緩存的問題：
1.1. 基本的緩存原理
Hibernate緩存分為二級，
第一級存放於session中稱為一級緩存，默認帶有且不能卸載。
第二級是由sessionFactory控制的進程級緩存。是全局共享的緩存，凡是會調用二級緩存的查詢方法 都會從中受益。只有經正確的配置後二級緩存才會發揮作用。同時在進行條件查詢時必須使用相應的方法才能從緩存中獲取數據。比如 Query.iterate()方法、load、get方法等。必須注意的是session.find方法永遠是從資料庫中獲取數據，不會從二級緩存中獲 取數據，即便其中有其所需要的數據也是如此。
查詢時使用緩存的實現過程為：首先查詢一級緩存中是否具有需要的數據，如果沒有，查詢二級緩存，如果二級緩存中也沒有，此時再執行查詢資料庫的工作。要注意的是：此3種方式的查詢速度是依次降低的。
1.2. 存在的問題
1.2.1. 一級緩存的問題以及使用二級緩存的原因
因為Session的生命期往往很短，存在於Session內部的第一級最快緩存的生命期當然也很短，所以第一級緩存的命中率是很低的。其對系統性 能的改善也是很有限的。當然，這個Session內部緩存的主要作用是保持Session內部數據狀態同步。並非是hibernate為了大幅提高系統性 能所提供的。
為了提高使用hibernate的性能，除了常規的一些需要注意的方法比如：
使用延遲載入、迫切外連接、查詢過濾等以外，還需要配置hibernate的二級緩存。其對系統整體性能的改善往往具有立竿見影的效果！
（經過自己以前作項目的經驗，一般會有3~4倍的性能提高）
1.2.2. N+1次查詢的問題
1.2.2.1 什麼時候會遇到1+N的問題？
前提：Hibernate默認表與表的關聯方法是fetch="select"，不是fetch="join",這都是為了懶載入而准備的。
1）一對多(<set><list>) ，在1的這方，通過1條sql查找得到了1個對象，由於關聯的存在 ，那麼又需要將這個對象關聯的集合取出，所以合集數量是n還要發出n條sql，於是本來的1條sql查詢變成了1 +n條 。
2）多對一<many-to-one> ，在多的這方，通過1條sql查詢得到了n個對象，由於關聯的存在,也會將這n個對象對應的1 方的對象取出， 於是本來的1條sql查詢變成了1 +n條 。
3）iterator 查詢時,一定先去緩存中找（1條sql查集合,只查出ID），在沒命中時，會再按ID到庫中逐一查找， 產生1+n條SQL
1.2.2.2 怎麼解決1+N 問題？
1 ）lazy=true， hibernate3開始已經默認是lazy=true了；lazy=true時不會立刻查詢關聯對象，只有當需要關聯對象（訪問其屬性，非id欄位）時才會發生查詢動作。
2）使用二級緩存， 二級緩存的應用將不怕1+N 問題，因為即使第一次查詢很慢（未命中），以後查詢直接緩存命中也是很快的。剛好又利用了1+N 。
3) 當然你也可以設定fetch="join"，一次關聯表全查出來，但失去了懶載入的特性。
執行條件查詢時，iterate（）方法具有著名的 「n+1」次查詢的問題，也就是說在第一次查詢時iterate方法會執行滿足條件的查詢結果數再加一次（n+1）的查詢。但是此問題只存在於第一次查詢 時，在後面執行相同查詢時性能會得到極大的改善。此方法適合於查詢數據量較大的業務數據。
但是注意：當數據量特別大時（比如流水線數據等）需要針對此持久化對象配置其具體的緩存策略，比如設置其存在於緩存中的最大記錄數、緩存存在的時間等參數，以避免系統將大量的數據同時裝載入內存中引起內存資源的迅速耗盡，反而降低系統的性能！！！
1.3. 使用hibernate二級緩存的其他注意事項：
1.3.1. 關於數據的有效性
另外，hibernate會自行維護二級緩存中的數據，以保證緩存中的數據和資料庫中的真實數據的一致性！無論何時，當你調用save()、 update()或 saveOrUpdate()方法傳遞一個對象時，或使用load()、 get()、list()、iterate() 或scroll()方法獲得一個對象時, 該對象都將被加入到Session的內部緩存中。 當隨後flush()方法被調用時，對象的狀態會和資料庫取得同步。
也就是說刪除、更新、增加數據的時候，同時更新緩存。當然這也包括二級緩存！
只要是調用hibernate API執行資料庫相關的工作。hibernate都會為你自動保證 緩存數據的有效性！！
但是，如果你使用了JDBC繞過hibernate直接執行對資料庫的操作。此時，Hibernate不會/也不可能自行感知到資料庫被進行的變化改動，也就不能再保證緩存中數據的有效性！！
這也是所有的ORM產品共同具有的問題。幸運的是，Hibernate為我們暴露了Cache的清除方法，這給我們提供了一個手動保證數據有效性的機會！！
一級緩存，二級緩存都有相應的清除方法。
其中二級緩存提供的清除方法為：
按對象class清空緩存
按對象class和對象的主鍵id清空緩存
清空對象的集合中的緩存數據等。
1.3.2. 適合使用的情況
並非所有的情況都適合於使用二級緩存，需要根據具體情況來決定。同時可以針對某一個持久化對象配置其具體的緩存策略。
適合於使用二級緩存的情況：
1、數據不會被第三方修改；
一般情況下，會被hibernate以外修改的數據最好不要配置二級緩存，以免引起不一致的數據。但是如果此數據因為性能的原因需要被緩存，同時又 有可能被第3方比如SQL修改，也可以為其配置二級緩存。只是此時需要在sql執行修改後手動調用cache的清除方法。以保證數據的一致性
2、數據大小在可接收范圍之內；
如果數據表數據量特別巨大，此時不適合於二級緩存。原因是緩存的數據量過大可能會引起內存資源緊張，反而降低性能。
如果數據表數據量特別巨大，但是經常使用的往往只是較新的那部分數據。此時，也可為其配置二級緩存。但是必須單獨配置其持久化類的緩存策略，比如最大緩存數、緩存過期時間等，將這些參數降低至一個合理的范圍（太高會引起內存資源緊張，太低了緩存的意義不大）。
3、數據更新頻率低；
對於數據更新頻率過高的數據，頻繁同步緩存中數據的代價可能和 查詢緩存中的數據從中獲得的好處相當，壞處益處相抵消。此時緩存的意義也不大。
4、非關鍵數據（不是財務數據等）
財務數據等是非常重要的數據，絕對不允許出現或使用無效的數據，所以此時為了安全起見最好不要使用二級緩存。
因為此時 「正確性」的重要性遠遠大於 「高性能」的重要性。
2. 目前系統中使用hibernate緩存的建議
2.1. 目前情況
一般系統中有三種情況會繞開hibernate執行資料庫操作：
1、多個應用系統同時訪問一個資料庫
此種情況使用hibernate二級緩存會不可避免的造成數據不一致的問題，此時要進行詳細的設計。比如在設計上避免對同一數據表的同時的寫入操作，
使用資料庫各種級別的鎖定機制等。
2、動態表相關
所謂「動態表」是指在系統運行時根據用戶的操作系統自動建立的數據表。
比如「自定義表單」等屬於用戶自定義擴展開發性質的功能模塊，因為此時數據表是運行時建立的，所以不能進行hibernate的映射。因此對它的操作只能是繞開hibernate的直接資料庫JDBC操作。
如果此時動態表中的數據沒有設計緩存，就不存在數據不一致的問題。
如果此時自行設計了緩存機制，則調用自己的緩存同步方法即可。
3、使用sql對hibernate持久化對象表進行批量刪除時
此時執行批量刪除後，緩存中會存在已被刪除的數據。
分析：
當執行了第3條（sql批量刪除）後，後續的查詢只可能是以下三種方式：
a. session.find（）方法：
根據前面的總結，find方法不會查詢二級緩存的數據，而是直接查詢資料庫。
所以不存在數據有效性的問題。
b. 調用iterate方法執行條件查詢時：
根據iterate查詢方法的執行方式，其每次都會到資料庫中查詢滿足條件的id值，然後再根據此id 到緩存中獲取數據，當緩存中沒有此id的數據才會執行資料庫查詢；
如果此記錄已被sql直接刪除，則iterate在執行id查詢時不會將此id查詢出來。所以，即便緩存中有此條記錄也不會被客戶獲得，也就不存在不一致的情況。（此情況經過測試驗證）
c. 用get或load方法按id執行查詢：
客觀上此時會查詢得到已過期的數據。但是又因為系統中執行sql批量刪除一般是針對中間關聯數據表，對於中間關聯表的查詢一般都是採用條件查詢 ,按id來查詢某一條關聯關系的幾率很低,所以此問題也不存在!
如果某個值對象確實需要按id查詢一條關聯關系,同時又因為數據量大使用 了sql執行批量刪除。當滿足此兩個條件時,為了保證按id 的查詢得到正確的結果,可以使用手動清楚二級緩存中此對象的數據的方法!!(此種情況出現的可能性較小)
2.2. 建 議
1、建議不要使用sql直接執行數據持久化對象的數據的更新，但是可以執行 批量刪除。（系統中需要批量更新的地方也較少）
2、如果必須使用sql執行數據的更新，必須清空此對象的緩存數據。調用
SessionFactory.evict(class)
SessionFactory.evict(class,id)等方法。
3、在批量刪除數據量不大的時候可以直接採用hibernate的批量刪除，這樣就不存在繞開hibernate執行sql產生的緩存數據一致性的問題。
4、不推薦採用hibernate的批量刪除方法來刪除大批量的記錄數據。
原因是hibernate的批量刪除會執行1條查詢語句外加 滿足條件的n條刪除語句。而不是一次執行一條條件刪除語句！！
當待刪除的數據很多時會有很大的性能瓶頸！！！如果批量刪除數據量較大,比如超過50條,可以採用JDBC直接刪除。這樣作的好處是只執行一條sql刪除語句,性能會有很大的改善。同時，緩存數據同步的問題,可以採用 hibernate清除二級緩存中的相關數據的方法。
調 用
SessionFactory.evict(class) ;
SessionFactory.evict(class,id)等方法。
所以說，對於一般的應用系統開發而言（不涉及到集群，分布式數據同步問題等），因為只在中間關聯表執行批量刪除時調用了sql執行，同時中間關聯表 一般是執行條件查詢不太可能執行按id查詢。所以，此時可以直接執行sql刪除，甚至不需要調用緩存的清除方法。這樣做不會導致以後配置了二級緩存引起數 據有效性的問題。
退一步說，即使以後真的調用了按id查詢中間表對象的方法，也可以通過調用清除緩存的方法來解決。
3、具體的配置方法
根據我了解的很多hibernate的使用者在調用其相應方法時都迷信的相信「hibernate會自行為我們處理性能的問題」，或者 「hibernate 會自動為我們的所有操作調用緩存」,實際的情況是hibernate雖然為我們提供了很好的緩存機制和擴展緩存框架的支持，但是必須經過正確的調用其才有 可能發揮作用！！所以造成很多使用hibernate的系統的性能問題，實際上並不是hibernate不行或者不好，而是因為使用者沒有正確的了解其使 用方法造成的。相反，如果配置得當hibernate的性能表現會讓你有相當「驚喜的」發現。下面我講解具體的配置方法。
ibernate提供了二級緩存的介面：
net.sf.hibernate.cache.Provider,
同時提供了一個默認的 實現net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的實現 比如ehcache,jbosscache等。
具體的配置位置位於hibernate.cfg.xml文件中
<propertyname="hibernate.cache.use_query_cache">true</property>
<propertyname="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>
<hibernate-mapping>
<classname="com.sobey.sbm.model.entitySystem.vo.DataTypeVO"table="dcm_datatype">
<cacheusage="read-write"/>
<idname="id"column="TYPEID"type="java.lang.Long">
<generatorclass="sequence"/>
</id>
<propertyname="name"column="NAME"type="java.lang.String"/>
<propertyname="dbType"column="DBTYPE"type="java.lang.String"/>
</class>
</hibernate-mapping>
很多的hibernate使用者在 配置到 這一步 就以為 完事了，
注意：其實光這樣配，根本就沒有使用hibernate的二級緩存。同時因為他們在使用hibernate時大多時候是馬上關閉session，所 以，一級緩存也沒有起到任何作用。結果就是沒有使用任何緩存，所有的hibernate操作都是直接操作的資料庫！！性能可以想見。
正確的辦法是除了以上的配置外還應該配置每一個vo對象的具體緩存策略，在影射文件中配置。例如：
關鍵就是這個<cache usage="read-write"/>，其有幾個選擇read-only,read-write,transactional,等
然後在執行查詢時 注意了 ，如果是條件查詢，或者返回所有結果的查詢，此時session.find()方法 不會獲取緩存中的數據。只有調用query.iterate()方法時才會調緩存的數據。
同時 get 和 load方法 是都會查詢緩存中的數據
⑷ java有哪些簡潔的ORM框架
java流行的框架這個就太多了，並且每天都在更新迭代，從一下幾方面總結。
1、整合資料庫的orm框架：Mybatis（batis）、Hibernate、Jpa、Jdo等
2、緩存以及分布式緩存：Ecache、Memcached、Redis等
3、web框架：WebWok、Struts2、SpringMvc等
4、遠程調用的相關的服務框架:bbo、webService等
4、其他大大小小，在各領域發揮的有很多，如日誌處理Log4J、sj4j，xml處理dom4j等等數不勝數。
⑸ struts+hibernate+spring結構整合後，action為什麼必須註解為多例的
hibernate工作原理
原理：
1.讀取並解析配置文件
2.讀取並解析映射信息，創建SessionFactory
3.打開Sesssion
4.創建事務Transation
5.持久化操作
6.提交事務
7.關閉Session
8.關閉SesstionFactory
為什麼要用：
1. 對JDBC訪問資料庫的代碼做了封裝，大大簡化了數據訪問層繁瑣的重復性代碼。
2. Hibernate是一個基於JDBC的主流持久化框架，是一個優秀的ORM實現。他很大程度的簡化DAO層的編碼工作
3. hibernate使用Java反射機制，而不是位元組碼增強程序來實現透明性。
4. hibernate的性能非常好，因為它是個輕量級框架。映射的靈活性很出色。它支持各種關系資料庫，從一對一到多對多的各種復雜關系。
2． Hibernate是如何延遲載入?
1. Hibernate2延遲載入實現：a)實體對象 b)集合（Collection）
2. Hibernate3 提供了屬性的延遲載入功能
當Hibernate在查詢數據的時候，數據並沒有存在與內存中，當程序真正對數據的操作時，對象才存在與內存中，就實現了延遲載入，他節省了伺服器的內存開銷，從而提高了伺服器的性能。
3．Hibernate中怎樣實現類之間的關系?(如：一對多、多對多的關系)
類與類之間的關系主要體現在表與表之間的關系進行操作，它們都市對對象進行操作，我們程序中把所有的表與類都映射在一起，它們通過配置文件中的many-to-one、one-to-many、many-to-many、
4． 說下Hibernate的緩存機制
1. 內部緩存存在Hibernate中又叫一級緩存，屬於應用事物級緩存
2. 二級緩存：
a) 應用及緩存
b) 分布式緩存
條件：數據不會被第三方修改、數據大小在可接受范圍、數據更新頻率低、同一數據被系統頻繁使用、非 關鍵數據
c) 第三方緩存的實現
5． Hibernate的查詢方式
Sql、Criteria,object comptosition
Hql：
1、 屬性查詢
2、 參數查詢、命名參數查詢
3、 關聯查詢
4、 分頁查詢
5、 統計函數
6． 如何優化Hibernate？
1.使用雙向一對多關聯，不使用單向一對多
2.靈活使用單向一對多關聯
3.不用一對一，用多對一取代
4.配置對象緩存，不使用集合緩存
5.一對多集合使用Bag,多對多集合使用Set
6. 繼承類使用顯式多態
7. 表欄位要少，表關聯不要怕多，有二級緩存撐腰
struts工作原理
Struts工作機制？為什麼要使用Struts？
工作機制：
Struts的工作流程:
在web應用啟動時就會載入初始化ActionServlet,ActionServlet從
struts-config.xml文件中讀取配置信息,把它們存放到各種配置對象
當ActionServlet接收到一個客戶請求時,將執行如下流程.
-(1)檢索和用戶請求匹配的ActionMapping實例,如果不存在,就返回請求路徑無效信息;
-(2)如果ActionForm實例不存在,就創建一個ActionForm對象,把客戶提交的表單數據保存到ActionForm對象中;
-(3)根據配置信息決定是否需要表單驗證.如果需要驗證,就調用ActionForm的validate()方法;
-(4)如果ActionForm的validate()方法返回null或返回一個不包含ActionMessage的ActuibErrors對象, 就表示表單驗證成功;
-(5)ActionServlet根據ActionMapping所包含的映射信息決定將請求轉發給哪個Action,如果相應的 Action實例不存在,就先創建這個實例,然後調用Action的execute()方法;
-(6)Action的execute()方法返回一個ActionForward對象,ActionServlet在把客戶請求轉發給 ActionForward對象指向的JSP組件;
-(7)ActionForward對象指向JSP組件生成動態網頁,返回給客戶;
為什麼要用：
JSP、Servlet、JavaBean技術的出現給我們構建強大的企業應用系統提供了可能。但用這些技術構建的系統非常的繁亂，所以在此之上，我們需要一個規則、一個把這些技術組織起來的規則，這就是框架，Struts便應運而生。
基於Struts開發的應用由3類組件構成：控制器組件、模型組件、視圖組件
8． Struts的validate框架是如何驗證的？
在struts配置文件中配置具體的錯誤提示，再在FormBean中的validate()方法具體調用。
9． 說下Struts的設計模式
MVC模式: web應用程序啟動時就會載入並初始化ActionServler。用戶提交表單時，一個配置好的ActionForm對象被創建，並被填入表單相應的數據，ActionServler根據Struts-config.xml文件配置好的設置決定是否需要表單驗證，如果需要就調用ActionForm的 Validate（）驗證後選擇將請求發送到哪個Action，如果Action不存在，ActionServlet會先創建這個對象，然後調用 Action的execute（）方法。Execute（）從ActionForm對象中獲取數據，完成業務邏輯，返回一個ActionForward對象，ActionServlet再把客戶請求轉發給ActionForward對象指定的jsp組件，ActionForward對象指定的jsp生成動態的網頁，返回給客戶。
spring工作原理
1.spring mvc請所有的請求都提交給DispatcherServlet,它會委託應用系統的其他模塊負責負責對請求進行真正的處理工作。
2.DispatcherServlet查詢一個或多個HandlerMapping,找到處理請求的Controller.
3.DispatcherServlet請請求提交到目標Controller
4.Controller進行業務邏輯處理後，會返回一個ModelAndView
5.Dispathcher查詢一個或多個ViewResolver視圖解析器,找到ModelAndView對象指定的視圖對象
6.視圖對象負責渲染返回給客戶端。
為什麼用：
{AOP 讓開發人員可以創建非行為性的關注點，稱為橫切關注點，並將它們插入到應用程序代碼中。使用 AOP 後，公共服務 （比如日誌、持久性、事務等）就可以分解成方面並應用到域對象上，同時不會增加域對象的對象模型的復雜性。
IOC 允許創建一個可以構造對象的應用環境，然後向這些對象傳遞它們的協作對象。正如單詞 倒置 所表明的，IOC 就像反 過來的 JNDI。沒有使用一堆抽象工廠、服務定位器、單元素（singleton）和直接構造（straight construction），每一個對象都是用其協作對象構造的。因此是由容器管理協作對象（collaborator）。
Spring即使一個AOP框架，也是一IOC容器。 Spring 最好的地方是它有助於您替換對象。有了 Spring，只要用 JavaBean 屬性和配置文件加入依賴性（協作對象）。然後可以很容易地在需要時替換具有類似介面的協作對象。}
Spring 框架是一個分層架構，由 7 個定義良好的模塊組成。Spring 模塊構建在核心容器之上，核心容器定義了創建、配置和管理 bean 的方式，如圖 1 所示。
組成 Spring 框架的每個模塊（或組件）都可以單獨存在，或者與其他一個或多個模塊聯合實現。每個模塊的功能如下：
☆ 核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要組件是 BeanFactory，它是工廠模式的實現。BeanFactory 使用控制反轉 （IOC）模式將應用程序的配置和依賴性規范與實際的應用程序代碼分開。
☆ Spring 上下文：Spring 上下文是一個配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企業服務，例如 JNDI、EJB、電子郵件、國際化、校驗和調度功能。
☆ Spring AOP：通過配置管理特性，Spring AOP 模塊直接將面向方面的編程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何對象支持 AOP。Spring AOP 模塊為基於 Spring 的應用程序中的對象提供了事務管理服務。通過使用 Spring AOP，不用依賴 EJB 組件，就可以將聲明性事務管理集成到應用程序中。
☆ Spring DAO：JDBC DAO 抽象層提供了有意義的異常層次結構，可用該結構來管理異常處理和不同資料庫供應商拋出的錯誤消息。異常層次結構簡化了錯誤處理，並且極大地降低了需要編寫的異常代碼數量（例如打開和關閉連接）。Spring DAO 的面向 JDBC 的異常遵從通用的 DAO 異常層次結構。
☆ Spring ORM：Spring 框架插入了若干個 ORM 框架，從而提供了 ORM 的對象關系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有這些都遵從 Spring 的通用事務和 DAO 異常層次結構。
☆ Spring Web 模塊：Web 上下文模塊建立在應用程序上下文模塊之上，為基於 Web 的應用程序提供了上下文。所以，Spring 框架支持與 Jakarta Struts 的集成。Web 模塊還簡化了處理多部分請求以及將請求參數綁定到域對象的工作。
☆ Spring MVC 框架：MVC 框架是一個全功能的構建 Web 應用程序的 MVC 實現。通過策略介面，MVC 框架變成為高度可配置的，MVC 容納了大量視圖技術，其中包括 JSP、Velocity、Tiles、iText 和 POI。
Spring 框架的功能可以用在任何 J2EE 伺服器中，大多數功能也適用於不受管理的環境。Spring 的核心要點是：支持不綁定到特定 J2EE 服務的可重用業務和數據訪問對象。毫無疑問，這樣的對象可以在不同 J2EE 環境 （Web 或 EJB）、獨立應用程序、測試環境之間重用。
IOC 和 AOP
控制反轉模式（也稱作依賴性介入）的基本概念是：不創建對象，但是描述創建它們的方式。在代碼中不直接與對象和服務連接，但在配置文件中描述哪一個組件需要哪一項服務。容器（在 Spring 框架中是 IOC 容器） 負責將這些聯系在一起。
在典型的 IOC 場景中，容器創建了所有對象，並設置必要的屬性將它們連接在一起，決定什麼時間調用方法。下表列出了 IOC 的一個實現模式。