CMP2.0在大型企业系统设计之中究竟应该使用到什么程度?有大型应用开发经历的人请进来一谈!

03-12-29 mysapphire
本人在对系统进行详细设计的时候遇到了困难,加上我以前一直想不同的问题,总结如下:

1 系统之中的所有表之间都是有关联的(一般情况都是这样的),而这样的话从EJB2.0的角度来讲,就应该把它们全部或者大部分映射成CMP(既然EJB2.0对性能的提升有了很大幅度的提升,那么我是不是可以这样使用CMP?),但是这样子的设计我担心风险会很大?因为我对CMP在高频度访问(包括查询和更改)情况下的性能不清楚(没有亲身经经历开发过测试,仅限于资料上查阅)。 很多人说:牺牲一点效率换来系统架构的灵活伸缩性是值得的,但象这样的情况会不会牺牲非常多的效率,以至于系统的负担过载?这个使用的量的控制我还不会把握。

2 CMP是能够在应用程序之间共享的,那么在访问数据频率越高的情况下性能体现得应该越卓越! 可是为什么还是有很多帖子说:为减低内存使用率,建议查询不要使用实体BEAN,而在更新的时候使用? 这岂不违背了EJB的存在目标了。而且这样的实现系统日后维护的工作量岂不是也成了双份的了?

3 按照mastering EJB(2nd)这本书里讲的,实体BEAN是数据封装的第一选择(尤其是CMP),并且可以通过一定的优化(如:设置总是使用LOCAL BEAN、对只读是BEAN设置成永久缓存、尽可能使用CMP等)来改善性能,那么我们是不是可以尽可能地使用它了呢?

最后回到我的主要疑问上来: 一个大型企业系统设计适合使用CMP来作为数据封装层吗? 如果不是,那么什么样类型的数据(表)应该挑出来改用其他方法实现?而什么样类型的数据(表)尤其值得用CMP封装呢?

(注:对于BMP我个人觉得适用的情况极少,大部分可以用session bean + JDBC来替代,而且如果真的要用,BMP的设计者也应该具有相当的程序和数据分析能力才能写得好,所以这里暂不提。)

****另外我发现几篇文章,其中之一地址如下,有兴趣的人可以去看看:

http://www.umlchina.com/CBD/ejb20.htm

在那里,作者介绍了CMP的依赖值对象(dependent value class)的概念,是一种轻量级的,替代CMR关系的解决办法。 我想如果有了这个东西的话,至少可以缓解一下滥用CMP的情况,为系统减轻一些负担。可是网上其他的文章都没有提到这个东西,在很多EJB容器的XML实施描述符里面也没有<dependents>这个标签,难道这个概念是错的? 有没有人可以为我解释一下?

         

mysapphire
2003-12-30 09:03
uping...

legolas
2003-12-30 11:32
其次要明白entity bean的机制

1. 对于每个entity ejb,container都会提供一个pool,pool-size可以设置,值就是这个ejb的实例数量,在pool里面的实例是没有身份标识的

2. 对于每个entity ejb,container还会提供一个cache,cache-size也可以设置,值就是这个ejb活动的实例数量,cache里面的实例是有身份标识的

3. container会在一定情况下会把cache里的实例钝化放回pool,比如cahce-size是3,cache的实例是a、b、c,这时某个线程访问d,container就会把abc中的一个,比如b,钝化放回pool,而把pool中的一个实例赋予身份标识放入cache中,如果又有对b的访问,则根据b的context中的信息填充pool中的一个实例放入cache

4.pool-size和cache-size也不宜设置太大,一般来说cache-size设置成对这个entity bean(注意,是指某个entity bean,而不是某个entity bean的某个实例)有可能的最大并发数大小,pool-size可比cache-size稍微大一点

搞清楚这个机制以后,我们再来讨论你说的这些问题

1.cmp2.0这个数据持久模型是非常优秀的,开发非常方便(如果你用支持ejb2.0的IDE工具的话),面向对象,支持事务,还有很多app server的优化支持;bmp不推荐使用,自己写这么多数据库访问的代码还不如直接用session bean+dao了。更新操作使用cmp,我们可以看到cmp的一些优势:实例有缓存;事务的隔离级别、并发策略、事务边界都是container manage的,可以通过部署文件配置,这些都是cmp的重要特性

2.查询不要使用entity bean是有根据的,从上面所述的机制中可以看出来,大数据量查询如果使用entity bean的话,会导致大量entity bean实例的生成,然后有很多的钝化、激活操作,必然影响效率,所以,建议用DAO模式好点,不管用什么持久模型,这样的查询都应该直接用jdbc才是高效的

3.如果对entity bean掌握的好,是可以开发出非常优秀的系统的,但俺不认为cmp是持久模型的必然选择,虽然它是目前比较成熟的持久性方案(相比其它的来说,其实它本身还是有很多需要完善的地方的),其它的诸如jdo、hibernate也是可选择的方案,自己哪个用的好就用哪个嘛,对不?

mysapphire
2003-12-30 13:54
我认为,既然采用了CMP2.0就应该使用它来解决系统中的大多数问题,否则如果只用了部分,是体现不出CMP的优势的!还不如都不用!因为CMR连接了各种CMP,来达到数据之间关系的封装,如果局部采用了CMP,那么肯定会有缺口,这样导致CMP和JDBC混用是肯定会增加工作量的。

再者:如果说使用查询来解决CMP的内存征用问题,那么在这里得到的收益,在程序上还是得用“增加代码冗余”和“维护工作量”来填回去的! 我觉得还是在原地踏步。 除非是为了系统响应速度而这么做,要是为了这个目的的话还不若寻找其他提高速度的方法。这又违背了EJB的目标--“封装底层数据操作复杂性”。

legolas
2003-12-30 17:16
这里说的查询不要使用entity bean指的是大数据量的查询,比如几百几千条的,一般的查询使用cmp当然没有问题,cmr及ejbql可以帮你实现大部分的查询

猜你喜欢
3Go 1 2 3 下一页