一般的数据库查询放到EntityBean的finder方法里好还是用SessionBean？
用finder方法查询好像一条纪录就是用一个Bean表示，还会抛出CacheFullException!
大家都用什么方法查询数据库呢？

1．远程对象和本地对象。Entity Bean是远程对象，而DAO是本地对象。因此对Entity Bean的访问速度要比对DAO的访问速度要低。 
2．容器管理的生命周期和客户管理的生命周期。Entity Bean的生命周期由容器管理，而DAO的生命周期由使用它的客户（一般是Session Bean）管理。在容器管理的生命周期中对Entity Bean的修改和实际数据库记录的更新分别有客户和容器完成，单个Entity Bean的修改性能要比单个DAO对象的修改高。在批量数据的处理上，由于DAO是一次性完成，性能比Entity Bean要好。 
3．Session Bean管理事务和Entity Bean管理事务。DAO的事务有客户（一般是Session Bean）负责，Entity Bean的事务由Entity Bean自身完成。Session Bean事务适合粗粒度的事务控制，而Entity Bean事务适合细粒度的控制。 
4．脏数据问题。一般来说我们采用value Object避免大量的琐碎的远程调用来获取数据，同时这也会给我们带来所谓的“脏数据”问题。在Entity Bean中可以使用Time Stamp来解决这个问题，但DAO看起来似乎难以解决。 
5．资源问题和激活/钝化瓶颈。大量的Entity Bean会消耗大量的资源，DAO同样如此。Entity Bean设计的目的不是为了操纵批量数据，而DAO是一般Java对象，可以这样使用。在Entity Bean或DAO对象数量巨大时，Entity Bean由容器管理其激活和钝化，以节省资源；而DAO对象需要自己设计这种机制，这是很困难的。同时管理DAO对象的Session Bean的激活和钝化过程会带来DAO对象的存储瓶颈，即在Session Bean的激活和钝化中，其所管理的DAO对象也要被写入外存储器。 
6．缓冲的实现。Entity Bean由容器实现缓冲（Cache），DAO对象本身很难实现缓冲机制。 
一般在只读的应用中使用DAO，而在创建和修改操作中使用Entity Bean。不建议使用Session Bean直接存取数据库的方式，应该对数据访问逻辑加