2，会话组件最好只通过普通JAVA数据存取接口的一个持久性门面来访问实体组件。虽然实体组件衽了一种特殊的数据处理方法，但标准JAVA接口却没有。这种方法不公保持了灵活性，而且还预见性地检验了一个应用。笔者对实体组件的未来产生了极大的怀疑，因为凡是在实体组件适用的任何地方，JDO都能提供一个更简单、更通用、性能更高的解决方案。通过使用DAO，我们仍有换用JDO或其他任一持久性策略的能力，即便在一开始就使用实体组件实现了一个应用之后。
3，实体组件通常是一 个薄层，用于具体化一个不是基于对象的数据存储器。如果使用一个像ODBMS之类的面对对象的数据存储器，这个薄层不是必需的，因为可以使用助手类从会话组件中访问这种数据存储器
4，关于实体组件的争论有两点：一）实体组件的粒度，二）实体组件是否可以实现业务逻辑。
5，一个粗实体可能会建模一条逻辑记录，而这条记录会分布于多个表中；而一个精细粒度可能会映射到单个表中；在EJB2.0 CMP中通常认为精细粒度会更加方便,虽然粗粒度的建模更利于面向对象的设计，但有一个结论就是：
在EJB2.0中，最好是通过使用CMP把实体组件用于相当精细的对象。
6,无论任何理由都不能破坏以下约定：
在实体组件中只实现持久性逻辑，不要实现业务逻辑！
7，BMP的“N+1”问题，对于BMP的find方法，它在EJB中的实现需要返回主键集合，在幕后BMP做了什么了？
如你要选取某个城市的全部人员信息，那么BMP会执行n+1次类这样的查询(n代表将要找到的记录)
SELECT PK,NAME, FROM USERS WHERE PK=
...
SELECT PK,NAME, FROM USERS WHERE PK=
如果你要查的数量少就还好，不幸的是如果你查询的记录比较多，如5000，这对于一个拥300万用户的系统来讲应该是很正常的查询，那么BMP会去自动执行5001次类似的查询。而任何正当的实现方法应该是类似以下的语句：
SELECT PK,NAME, FROM USERS WHERE PK IN
结论：不要实体组件中使用BMP，而要从无状态会话组件中使用持久性。和从一个DAO层中执行数据存取相比，使用BMP不会增加什么价值，只会增加复杂性。
8，CMP2.0引进了主业务方法（我平时叫home方法)，每个实体有自己的业务方法（远程接口中定义的方法）；两者均可以通过调用ejbSelect()方法来获取想要进行的逻辑操作，当然也可以作任何其它操作，如调用存储过程等。
9,应该使用DAO来分离数据数据存取与业务逻辑。当然DAO中是可以用无状态会话BEAN来实现的。
未完待续
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
