最近，Spring很熱鬧，因為實現IoC模式和AOP（見本站專欄），然后又成立公司，吸取上次JBoss的教訓，文檔不敢收費，結果迎來了一片祝賀聲。

　　Spring真正的精華是它的Ioc模式實現的BeanFactory和AOP，它自己在這個基礎上延伸的功能有些畫蛇添足。

　　其實說白了，大家"驚奇"的是它的IoC模式(使用AOP功能需要了解AOP，比較難)，那么，Spring之類的Ioc模式是什么？ 就是：你在編制程序時，只要寫被調用者的接口代碼，具體子類實例可通過配置實現。

　　Ioc模式是什么知道的人不多，但是，當他知道生成對象不用再使用new了，只要在配置文件里配置一下，他感到新鮮，其實這就是Ioc模式的實現，PicoContainer是另外一種真正輕量的Ioc模式實現，PicoContainer還是采取代碼將對象注射一個小容器中，而Spring采取配置文件。

　　配置式編碼其實有利有弊，編碼本來可通過開發工具或編譯器檢查錯誤，但是過分依賴配置時，就會經常出現因為粗心導致的小錯誤，如果調試程序出錯經常是因為配置文件中小寫字母寫成大寫字母，不知道你是怎么心情？

　　Spring最近還發表了Spring without EJB的書，這倒是說了實話，Spring和EJB其實是相競爭，如同黑與白，如果硬是將兩者搭配使用，顯得不協調，更不是一些人所謂優化EJB調用的謠言，原因下面將會分析。既然Spring+EJB有缺陷，那么就直接使用Spring+Hibernate架構，但是又帶來了新問題：無集群分布式計算性能，只能在一臺機器上運行啊，具體分析見：可伸縮性和重/輕量，誰是實用系統的架構主選？

　　下面來分析所謂Spring+EJB的不協調性，正如水和油攪拌在一起使用一樣。
　　目前，Spring+EJB有兩種應用方式：

　　1. Spring不介入EJB容器，只做Web與EJB之間的接口，這個位置比較尷尬，Web層直接調用EJB的方法比較直接快捷，為什么要中間加個Spring？可實現Web緩存？使用性能更好的AOP框架aspectwerkz??；實現Web和EJB解耦？這樣的工具更多，自己都可以做個小框架實現，就不必打擾背著AOP和IOC雙重重擔的Spring了吧。

　　2. Spring介入EJB容器，這時，需要在你的ejb-jar.xml中配置beanFactoryPath值指向你為EJB配置的applicationContext.xml，那么你的EJB還需要繼承Spring的SimpleRemoteStatelessSessionProxyFactoryBean。

　　好了，現在你的SLSB（無狀態Session Bean）成為下面這個樣子：

　　void updateUser(){
　　　　
　　　　　　myService.updateUser(); //委托給一個POJO的方法，真正業務邏輯封裝在這個POJO中

　　}

　　這樣做有很多“優點”，當然最大“優點”是：

　　由于真正業務核心在POJO中實現，因此，只要改一下applicationContext.xml配置，這樣，調試時，前臺就可以直接調用POJO，不必通過EJB，調試起來方便了，這有一個前提：他們認為調試EJB復雜，其實不然，在JBuilder中，結合Junit，測試EJB如同測試POJO一樣方便，這是其他分支，不在此討論。當部署使用時，再改一下applicationContext.xml配置，指引前臺調用到EJB。

　　似乎很巧妙，這里有兩個疑問，首先，指引到EJB的改變是什么時候做？持續集成前還是后，在前在后都有問題，這里不仔細分析。

　　這種表面巧妙的優點帶來最大的問題是：粗粒度事務機制。所謂粗粒度事務機制，最早見于Petstore的WEB調用EJB Command模式，在這個帖子中有討論。

　　下面以代碼描述什么是粗粒度事務機制：

　　ejb方法：
　　public void updateUser(){
　　　　service.updateUser();
　　}

　　service是一個POJO，具體方法可能是更新兩個表：
　　public void updateUser(){
　　　　updateTabel1();//更新table1
　　　　updateTable2(); //更新table2
　　}

　　當updateTable2()拋出異常，updateTable1()是不回滾的。這樣，table1中就有一條錯誤的多余的記錄，而table2則沒有這條記錄。

　　那么，怎么做才能使兩個表記錄一致，采取事務機制，只有下面這樣書寫才能實現真正事務：
在EJB方法中寫兩個方法，因為EJB方法體缺省是一個事務。
　　public void updateUser(){
　　　　updateTabel1();//更新table1
　　　　updateTable2(); //更新table2
　　}

　　關于EJB自動的事務機制，最近也有一個道友做了測試，對于JBoss中容器管理的事務的疑惑。

　　如果你從事關鍵事務，就是帶money相關操作的事務，這種粗粒度機制可能害苦你，那么，似乎有一種辦法可彌補事務，不使用EJB容器事務(CMT)，在service中使用Spring的事務機制。

　　如果使用Spring事務機制，業務核心又在POJO中實現，那么我有一個疑問：還要套上EJB干什么？至此，你終于明白，Spring本質是和EJB競爭的，如果硬套上EJB使用，只是相借助其集群分布式功能，而這個正是Spring目前所缺少的。

　　我太驚異Spring精巧的詭異了，他和EJB關系，正如異型和人的關系一樣。

　　為了避免你每次使用Spring時想到粘糊糊的異型，不如Spring without EJB，這也正是Spring的初衷，也是它的一個暢銷書名。

?