JPA

適合J2SE和J2EE的簡單框架，并入了其他框架的許多有用特性，但是需要Java 5或更高版。

CMP Entity EJBs
J2EE容器所支持的框架，擁有安全和事務(wù)管理、很好的可伸縮性、以及分布式的組件能力，但是耗費資源且學習和使用較為復雜。

Hibernate

簡單、靈活的框架，完全免費且易于與其他框架集成，但由于是開源的，因而可能有支持問題。

TopLink

Oracle的中心框架，十分成熟，但是使用它意味著綁死在一個單一廠商上。

該文章引發(fā)了相當數(shù)量的評論，尤其是圍繞著JPA和EJB 3.0中的Entity Beans之間的關(guān)系、以及作為開源框架的Hibernate的潛在不利因素方面的評論。

一個評論者在其關(guān)于Entity Beans和JPA的評論中這樣寫道：

該文章討論了使用JDBC的Bean-Managed Persistence (BMP)與Container-Managed Persistence之間的對比，但是EJB3.0為實體bean持久化引入了一個全新的模型。我必須假設(shè)作者在這里討論的是EJB 2.x?！斑h程接口模型”的討論也暗示了作者仍然在談?wù)揈JB 2.x，而且他文章中的大部分針對Enterprise JavaBean的背景信息及所羅列的缺點實際上是對EJB 1.x和 EJB 2.x而言的，而非針對EJB 3.0。這有點混亂，因為作者提及了EJB 3.0使用注解消除了許多伴隨在以前版本EJB左右的編碼困難。但是在下一個句子里他接著說道，“EJB架構(gòu)的學習和使用絕非易事”，并且羅列了一些以前EJB版本的一些常見問題。作者還談到了EJB在其他框架中不能使用，但是EJB 3.0使用了“普通”Java類，它可以在其它框架中使用，只要這些框架忽略掉該普通Java類的JPA注解即可。JPA作為EJB 3規(guī)范的一部分被創(chuàng)建，而且是EJB 3的固有部分。該規(guī)范制定者確定符合JPA規(guī)范的實現(xiàn)應(yīng)當支持SE環(huán)境。該作者提到了JPA在EJB和SE環(huán)境下都可以工作，但是接著又說要使用JPA，Java EE 5是必須的。這不是事實，因為要使JPA工作，SE并不需要依賴于EE。該篇文章所羅列的JPA的一個“不利因素”是JPA的能力受限于實現(xiàn)廠商。事實是“廠商”必須實現(xiàn)所有規(guī)范要求，包括Hibernate（它也是一個JPA實現(xiàn)的“廠商”）。有些人可能不得不自己寫類庫或框架，唯一的問題是他們所寫的類庫或框架是否與標準兼容。而其他一些人所涵蓋的框架“可能”是基于標準的（構(gòu)建在標準之上），Java對象關(guān)系映射持久化框架自身就是標準，它是一套Java持久化API。EJB 3.0和JPA之間是單向依賴。任何EJB 3.0實現(xiàn)應(yīng)當被預(yù)期為是大量基于JPA的，但是JPA出現(xiàn)并不意味著EJB必須出現(xiàn)，因為Java SE可以使用JPA。

另一個抱怨把開源作為一個不利因素的描述如下：

我認為我不同意你關(guān)于“開源是不利因素”的直白敘述。實際上，這種論調(diào)具有一定的誤導，它實際上可能會給你的項目增加不利因素。我所工作的一個項目決定用Kodo替代Hibernate，僅僅因為LGPL還不夠友好（不利因素，等等）。當我看了代碼之后我發(fā)現(xiàn)這是多么錯誤的一個決定……Hibernate那時遠遠勝出而且現(xiàn)在我仍然這么看?，F(xiàn)在維護起來困難且棘手。工作量完全不一樣…… 

盡管如此，有些人還是插話表達對作者主張的支持：你會將賭注押在誰身上呢？

開源項目通?！笆恰币粋€不利因素，而且Hibernate確實有嚴重的支持問題。除非你向該組織付費，否則你將發(fā)現(xiàn)他們的支持非常糟糕。Bug報告和特性要求將伴以粗陋的評論而被關(guān)閉掉。張貼在論壇上的討論會被忽略。普通（免費）支持將來也會很困難。任何正在考慮使用Hibernate的人應(yīng)該認識到，90%的時間它會像魔法一樣在工作，但是你將會浪費“數(shù)以天計”的時間修改那剩下的10%。他們通過使產(chǎn)品更難使用和掌控支持來獲利，這是他們掙錢的方式，就像其他開源項目一樣。Hibernate***的易用性問題是其異常消息。有時你會得到一個誤導性的錯誤信息，把你引向一個錯誤的方向。還有時你會得到非常模糊的信息，讓你無法判斷什么地方出了錯。如果你提出一個RFE，要求他們改善錯誤報告，你將會得到一個粗陋的評論，而且這個RFE將迅速被關(guān)閉。這只是我的個人看法。