设计EJB的方法，请各位老大赐教

Question

那使用EJB和不使用EJB差不了多少。
EJB中Entity Bean本身就是实体对象了，add delete update方法自然也就包含了，你只需要create就可以add，remove就可以delete，setXXX以后就自动update了，所有这些都是EJB Container来完成的。
要正确的使用EJB，一定要很好的理解EJB体系，才能设计出符合体系的系统来，因为一个系统有多种实现方法，就看你的方法是否更合理。

Answer 1

给你一个学习的地方
http://61.144.28.245/hjc/web/doc/ejb/ejb.html

Answer 2

小小说的对，entitybean是一部分，ejb的关键在于设计和封装良好的商业逻辑，无论维护还是重用都方便，所以你还是考虑逻辑，设计sessionbean的接口吧

Answer 3

我们基本上没用entity bean ，基本上都是用的session bean 
不知是否可行

Answer 4

楼上的可行,EntityBean效率实在是~

Answer 5

那如果没有分布式的需要，我觉得SessionBean都可以用一般的Bean来写，这不是效率更高吗？何必再一台服务器中还要用EJB呢？EJB中的EntityBean就是提供一个对象持久化的一种方法，这也是EJB最大的特色，虽然效率低一些，但ejb2.0已经改进很多了。

Answer 6

既然是都用sessionbean，那么又何来'把基本表每个都设计成一个EJB',这样要做的重复性工作不是太多了吗。
还是建议使用ENTITYBEAN，它完全就是为数据的持久表示而设计的，和会话BEAN不同，它不因容器的关闭而有任何的状态回复。

Answer 7

不好意思，上文中说的“那就不要在每个业务逻辑中都写相似的方法"应该改为
"那就不要在每个业务逻辑中都写相似的SQL语句"，这样查错也好查，因为对表的操作只有一个入口

Answer 8

如果真用J2EE实现；
我觉得还是尽量使用Entity Bean;
尤其是EJB2.0以后；

Answer 9

to  toadnet(哓哓) ,
    这种对数据表操作的思维方式（面向数据）对我们的影响很大也是很深的，但对于基于面向思想的J2EE来说，有点不合时宜了。对业务逻辑来说，我们对业务数据做业务操作，好像对其逻辑数据操作抽象为add/delete/update很是直接和自然，但我们是不是剥掉很多不应该舍去的东西，那就是，也还是业务逻辑。所以，以前我们的系统建立在面向数据的基础上，看似很稳，实际是空中阁楼，一旦风雨来（业务需求一变更），就塌了，就其本质在于业务架构的把握，而不是纯数据架构。
    如果更好的设计更稳健的（robust）J2EE系统，因该掌握好面向对象的设计思路，首先应该注意下:
    Boundary-Control-Entity的分析模式。

Answer 10

请 lcgong(踏雪) 兄能否再详细解释一下？？

Answer 11

我个人认为一般的技术是可以边学边干，而ejb则不一样分布是应用具有很强的扩展性等优点，但同样它也一些很难伺候的方面因为远程调用，每一次方法调用都要建立一次网络连接、数据传递、连接断开过程，这样对资源的占用比较大，因此如何合适的设计进程粒度和数据粒度，减少资源的开销很重要这一点我感觉比较难以掌握

Answer 12

如果你熟悉面向对象的方法的话，你就可以体会到其实没一个ejb就是一个对象，ejb中的变量就是对象的属性，而方法就是对对象的属性进行操作所以，不应该简单的把ejb和单表对应起来，而应该对应对象。如果你的数据库的设计也是基于对象的，你就会知道其实每个对象在数据库中是用多个表表示的（也会有单表的情况出现，但是比较少，主要是从性能的方面考虑）。在这个思路下，你可以很快确定你的ejb设计，再从众多的对象中分出层次，就可以看出所谓的继承等关系。很高兴一起谈论。