Hibernate、EJB/CMP的比较

Hibernate的优点：

● 有着正确的数据模型。以POJO为基础的模型是个正确的方向。

● 可配置性(例如对象之间的关系)是个很好的基础。

● HSQL正是O/R映射语言应该有的。

● 有着完整的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如果作为一个规范的话，还是不够干净。例如，在使用查询参数(query parameters)时，存在一些应用漏洞。

● 我不认为使用类名作为表的标识是件好事。

EJB/CMP的优点：

● 采用工厂类(指Home)查找实例比向Session/Connection对象传递参数获取实例要好。

● ejbSelect跟上面说的类似。

● 查询名称使用abstract schma是一个很好的解决方案。

● 理论上来说，这种模式在某些方案中可以有更好的复用性。

EJB/CMP的优点：

● CMP不属于EJB规范。它并不是个合适的模型去实现这个目的。已经没有合适的(例如非官方)借口去让EJB3.0中保留CMP。

原文内容： 

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.