再提两个问题！关于entity bean 和 session bean，谢谢高手解答。

Question

1. 容器会维护一个entitybean的实例缓冲池，这一点不用你操心，当然必要的时候你可以对实例池进行配置。2. 为页面显示而抽取数据的时候，把id和name都抽出来，name用于显示，id用于唯一标志一本书。

Answer 1

1、也就是说可以由sessionbean调用entitybean来完成这个操作是吧，即使数据量比较大也是没有问题的是吧？2、可能我描述的不清楚，我的意思是，书有若干属性而这些属性都是用ID标识的，书的entitybean是不是必须由sessionbean将这些属性的ID先转换成各自对应的name再传给客户端。如果客户端要查询500个书的对象，而每个对象都要由sessionbean到数据库中将每个属性的ID转移成name，如果有5个这样的属性，是不是要连2500次数据库？

Answer 2

1、一个实体BEAN对应的表可不可以不经过该实体bean而是由session bean来写数据或更新数据？
答：当然是这样的，最好的处理还是写在sessionbean中。
这里建议你在你的entitybean中写两个方法：1.getVO();2.setVO()
然后你直接就可以在你的sessionbean中的更新方法中写就行
2.
答：至于你的第二个问题“而这些属性在表中是以ID的形式存在的”我还没有明白你的意思

Answer 3

可以一次就把所有的数据读出来不就行了比如把所要请求的安ID放到List中，读出的数据也是按ID的形势组成List返回给用户

Answer 4

》》。如果客户端要查询500个书的对象，而每个对象都要由sessionbean到数据库中将每个属性的ID转移成name，如果有5个这样的属性，是不是要连2500次数据库？shit!！拜托，谁让你连2500次数据库？？？？你不会用关联查询？？？

Answer 5

yeshucheng :
1、你的方法是还是要经过entitybean的是吧，也就是说sessionbean不能绕开实体bean更新数据库是吧。
2、“这些属 性在表中是以ID的形式存在的”，是指在t_book表中的作者是以作者ID记录的，而另一个表中记录了作 者ID和name的对应关 系。

Answer 6

wzrlover(无语无声无欲无泪吾独行!) 
shit!！拜托，谁让你连2500次数据库？？？？你不会用关联查询？？？
============================但是先有entitybean对象，但它的作者属性是ID，所以我要通过ID去分别找作者的name，不对吗？

Answer 7

对你的第二个问题，建议将常用的id---name对缓存，在显示的时候不用查数据库，直接从缓存中读取。整个系统可以做一个入口，如Loader.getBookName(id).这个方法将图书Id转换成名称,在这个getBookName方法不是直接去查数据库,而是先判断缓存中是否已经存在该ID--name对,若没有才查询,否则,直接转换

Answer 8

问题2.最好是改table的设计，属性id后再加个属性名称，适当的冗余可以提高查询效率；
不然的话，可以建crm，只是效率会有折扣；

Answer 9

第二个问题好象以上二位的答案我都不是很满意：
一、缓存的方式如果这种Id（员工ID，设备ID，bookID……）太多的话可能不是很方便。
二、sgdb(神天月晓)的回答也有上面的问题，如果用冗余，我员工一改名，设备一改名，我要找到所有用到的地方去改名，也不是很科学。

Answer 10

1，至于效率问题，你应该实际去做测试，不应该挂在EJB上，这才能够对比效率，如决定用EJBSB-EB，你更需要按照逻辑去选择EB。2，你不能叫EJB去为你数据库设计打补丁，这里只建议你使用BMP或重设计库。这样就可以控制load和store，当然表的逻辑就比较好封装了。不要以为用EJB就会比DAO+hibernate好，这要针对方案。EJB本身就还在完善。

Answer 11

这么说来这个应该是EJB的老大难问题了，正在学习hibernate希望它能帮我解解决这个问题。

Answer 12

我没说EJB不好，我是占在方案对比的角度和你说的，你使用BMP能轻松解决你的第二个问题。regards

Answer 13

呵呵，一直没有人解惑，所以捞起来了。
BMP我感觉麻烦了点，项目大的话也不实用，或者说我水平有限，呵呵