JDO的優(yōu)點：
● JDO的生命周期狀態(tài)機(lifecycle state machine)是正確的用法。任何其它的O/R映射工具都應(yīng)該使用JDO的生命周期或者它的子集(例如：如果不支持事務(wù))。記住，JDO生命周期是為JDO實現(xiàn)服務(wù)的。大部分用戶不需要了解其中很復(fù)雜的內(nèi)幕。網(wǎng)頁Amber生命周期中有些圖示。
● PersistentManager API對如何管理JDO對象的狀態(tài)有一定的優(yōu)勢和價值。
JDO的缺點：
● 查詢(query)支持不完全。它應(yīng)該使用類似Hibernate的HSQL查詢語言，并使用java.sql.ResultSet作為查詢結(jié)果。
● 用于重載方法的字段擴展讓人覺得比較混亂。最好使用類似Hibernate或者EJB/CMP的方法，并重載它們。
Hibernate的優(yōu)點：
● 有著正確的數(shù)據(jù)模型。以POJO為基礎(chǔ)的模型是個正確的方向。
● 可配置性(例如對象之間的關(guān)系)是個很好的基礎(chǔ)。
● HSQL正是O/R映射語言應(yīng)該有的。
● 有著完整的API
● 采用簡明的Session類作為控制流的清洗器，因為它沿用了Connection的模型
Hibernate的缺點：
● 沒有使用JDO生命周期，這是不正確的做法。
● API(例如查詢)還是有點混亂。It's better than the alternative, but using java.sql.ResultSet as the foundation would clean it up.
● API如果作為一個規(guī)范的話，還是不夠干凈。例如，在使用查詢參數(shù)(query parameters)時，存在一些應(yīng)用漏洞。
● 我不認(rèn)為使用類名作為表的標(biāo)識是件好事。
EJB/CMP的優(yōu)點：
● 采用工廠類(指Home)查找實例比向Session/Connection對象傳遞參數(shù)獲取實例要好。
● ejbSelect跟上面說的類似。
● 查詢名稱使用abstract schma是一個很好的解決方案。
● 理論上來說，這種模式在某些方案中可以有更好的復(fù)用性。
EJB/CMP的優(yōu)點：
● CMP不屬于EJB規(guī)范。它并不是個合適的模型去實現(xiàn)這個目的。已經(jīng)沒有合適的(例如非官方)借口去讓EJB3.0中保留CMP。
Amber優(yōu)點：
● 使用JDBC ResultSet和PreparedStatement做查詢
出于某些原因，O/R映射工具通常拋棄強大的ResultSet和PreparedStatement API，而創(chuàng)建自己一套并不是很合適的替代品。O/R查詢器應(yīng)該使用一個外部的SQL(例如HSQL)作為查詢語言，并使用ResultSet作為結(jié)果集，使用PreparedStatement處理查詢參數(shù)。可以增加其它的API作為查詢子集，就像查詢一個單獨的實體，但應(yīng)該使用ResultSet和PreparedStatement作為基礎(chǔ)。
Amber缺點：
● Amber的研究價值遠大于它的使用價值
原文內(nèi)容：
JDO pros:
The JDO lifecycle state machine is the correct one. Any serious O/R mapper needs to use the JDO lifecycle or a subset (e.g. if transactions aren't supported.) Remember, the JDO lifecycle is for JDO implementors. Most users don't need to see the gory details. The Amber lifecycle page has some diagrams.
The PersistentManager API has some positives, valuable for managing the state of JDO objects.
JDO cons:
The query support is completely inadequate. It should use something like Hibernate's HSQL, and should use java.sql.ResultSet as the query result.
The promotion of fields to overloaded methods is messy. It's better to start with methods like Hibernate or EJB/CMP and overload them.
Hibernate pros:
The data model is correct. The POJO model using methods as the basis is the right way to go.
The configuration, esp for relations is a good basis.
HSQL is just about what an O/R map language should be.
The API is adequate.
The explicit Session makes the control flow cleaner, since it follows the Connection model.
Hibernate cons:
It doesn't use the JDO lifecycle model. This is incorrect.
The API, esp the query, is still a bit messy. It's better than the alternative, but using java.sql.ResultSet as the foundation would clean it up.
The API isn't clean enough for a spec, i.e. it has a number of implementation hacks, esp with the query parameters.
I'm not convinced using the class name as the table identifier is a good thing.
EJB/CMP pros:
The factory (home) classes are nice for finding instances rather than passing extra parameters to a Session/Connection object.
The ejbSelect is similarly
Using the abstract schema for the query names is a good solution
In theory, the model can allow for efficient object reuse in some cases
EJB/CMP cons:
CMP does not belong in the EJB spec. It's been contorted to follow a model that's not appropriate for the task. There's no valid, i.e. non-political, excuse for keeping CMP in EJB 3.0.
Amber pros:
Using the JDBC ResultSet and PreparedStatement for queries.
For some reason O/R mappers generally throw out the powerful ResultSet and PreparedStatement API and create their own hacked up and inadequate replacements. O/R queries should use an extended SQL like HSQL as the query language and use ResultSet for results and PreparedStatement for query parameters. Other specialized APIs can be added for particular subsets, like quering a single entity, but the foundation should be ResultSet and PreparedStatement.
Amber cons:
Amber is an experiment rather than an actual competing API.