1.3.4 考虑使用EJB实体Bean

近年来，EJB实体Bean成为了一种推荐的数据持久方式。如果你曾经开发过Java商业应用的话，那么你十分有可能和EJB打过交道。如果你没有接触过EJB的话，你也不用担心，因为它的时代马上就要过去了（当然，EJB3.0可能会带来一些新的希望）。

实体Bean很有趣，因为它完全是由一个委员会创建的。其他解决方案（例如DAO，序列化和ORM），都是从多年的经验中总结而来，同时也经历了许多的测试。但是，在实际应用中，EJB2.1似乎已经演变成了一场灾难。设计上的缺陷导致了EJB（BMP）工作的并不尽如人意。相比较而言，CMP是一个更好的选择。

然而，CMP并不能描述对象/关系的不匹配，有以下六点原因：

1 CMP bean被定义为和表一对一的关系，这种粗粒度的划分方式，不能够充分利用Java丰富的数据类型，从某种意义上来说，CMP强迫你进入第一范式；

2 从另一方面说，CMP为了实现EJB组件重用的目标，它又显得过于细粒度了。一个重用的组件应该是粗粒度的，对于数据库schema有着稳定的接口。

3 虽然EJB充分的利用了继承的优势，但是却不支持多态的联系和查询，但这却是ORM的一个必要的特征。

4 实体Bean，除了规范中那些实现了状态的目标意外，在实际中并不好用：各个厂商实现的EJB引擎各不相同，同时它们的配置文件也是千差万别。许多项目之所以选择Hibernate就是因为看中它是一种轻量级的框架并且不会被某个个别的厂商限制住。

5 实体Bean不能被序列化，所以当我们要给远端的客户层传输数据的时候，就必须定义单独的DTO对象。使用客户端调用远程实体Bean的方法并不利于升级；DTO提供了批量访问远程数据的方式。DTO模式也造成了重复的累继承关系，领域模型中的实体同时被表示为DTO和实体Bean。

6 EJB是一种插入式的模型，它违背了java常规的使用方法，造成了你很难在特定的容器之外的地方重用这些代码。这种特性并不利于那些测试驱动的开发，同时它也会在批量执行和其他离线功能的程序造成问题。

我们并不打算花费很长的篇幅来讨论EJB的优缺点。通过快速浏览了EJB的持久化特性之后，我们能够得出结论它并不适合对象映射。也许这在EJB3.0中将得到很大的改进。现在我们就看看另外一种吸引我们注意的持久化解决方案。