1，实体组件只是EJB层中的实现选择之一。实体组件不应该被暴露给客户软件。WEB层和其他EJB客户软件绝不应该直接访问实体组件。它亿只应该与由实现应用业务逻辑的会话组件所构成的一个会话组件层打交道。这不仅保持了应用设计与实现中的灵活性，而且常常还改进了性能。
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来实现的。
未完待续
