今天TSS和InfoQ都轉了一篇Spring與EJB3的讀后感，我就看了下，標題和介紹滿吸引人的。內容嘛其實有點不過癮，但是先記錄下來吧。
http://www.devx.com/Java/Article/32314/0/page/1總的來看Spring+Hibernate與JPA很相似，它們都是基于pojo的持久化。
Hibernate Session和JPA Entity Manager基本上等價，但是要記住他們的兩個重要區別。Hibernate session是一個實體緩存也是一個ORM引擎的接口。而JPA中這兩個概念是分開的。Persistence context作為緩存而entity manager則作為ORM引擎的接口。
當然還有顯而易見的區別，Spring+Hibernate偏向使用XML配置映射，而JPA偏向使用Annotation，雖然兩者都有XML和注釋兩種實現。
還有，JPA是一個標準，而Spring是對不同實現的抽象，兩者的方向是不同的。JPA的方式更徹底，Java傳統中都是這樣的。
JPA的主要商業實現有Hibernate、Kodo、Toplink，被巨鱷們看好。
后面，說到了關于Cache和Transaction管理的問題，由于Spring的草根特性，為了兼容實現，它使用Tread local這種編程式的方式。而EJB 3.0則由容器自動完成這些過程。而且EJB 3.0提供了不同的persistence context范疇，可以比較方便的管理持久數據的生命周期。不過，這個觀點很難說，因為如果你把Spring也看成一種容器，那么這Thread local對于你來說也是透明的，可以認為差不多。
關于EJB 3.0對生命周期的規定，讓持久化的概念更清楚了，如果這些東西能夠通過聲明而不是編碼來實現應該是愜意的，可是，問題就是很多程序員一般就喜歡自己控制，不喜歡那么透明，所以EJB一直以來興建的這些漂亮模型總是只有少數人使用，不是么？
在事務方面，由于兩者都支持生命性事務，所以程序本身看起來基本一樣。
區別在于配置。Spring還是偏向XML，并且事務作為Spring對AOP應用的經典樣例，transaction完全作為附加語義，可以通過配置替換各種事務實現，從JDBC、Hibernate到JTA，顯然這是從編程者角度考慮的，門檻很低。
而EJB 3.0則只支持JTA，這就需要容器的支持，當然跨多資源的事務往往是企業級項目的特性，所以這種思路可以理解。而且現在也有很多開源的JTA實現了，它們完全可以讓你的應用在商業EJB容器外運行。還要提一點，EJB3默認是配置上事務的，需要聲明才可覆蓋，這說明了EJB3對于企業應用的態度。
在JTA事務可以通過聲明就以橫切關注點的形勢注入的時候，JTA的成本已經下降了，所以一開始就用這種API完全可行。
這篇文章中關于狀態的地方我有點不太理解，里面說Spring的prototype等價于EJB的SFSBs，實現stateful。
EJB 3.0在這方面無疑是強大的，因為本身在這方面它就是個容器規范，Java EE容器都會提供這種高級的生命周期管理，并且把生命周期作為變成模型中非常重要的一部分。所以結果就是EJB 3.0在這方面領先于Spring，聲名簡單，并且從實現的方式上來說，EJB 3.0在性能上和可伸縮性上有明顯的優勢。Spring在性能伸縮或者說分布部署的時候應該說是捉襟見肘的，Terracotta也許可以解決些，但還……
應該說，實際上Spring提供的prototype就是new的另外一種實現，只不過它會經過Spring裝配，所以它叫做prototype，也就是“原型”，Spring每次回new出一個新的，按你的要求。當然，由于是類似new，所以Spring通過代理的方式管理起生命周期，也就能模擬出session、request、global session的statefull，不過這些功能顯然不算強項，在Spring 2.0中加強了（以前只有singleton和prototype），但依然不支持事務范疇，這就明顯不如EJB 3.0了。但是，回想Spring的編程哲學，它不要解決這種問題，這種問題留給容器解決:D
文章最后的總結比較官腔，基本上就是在說Spring靈活，EJB 3.0強大簡單，它們各有優缺點，所以應該結合起來使用，具體大家可以看看原文。