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

本人在对系统进行详细设计的时候遇到了困难，加上我以前一直想不同的问题，总结如下：
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>这个标签，难道这个概念是错的？有没有人可以为我解释一下？

uping...

其次要明白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

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

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

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

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

我认为，既然采用了CMP2.0就应该使用它来解决系统中的大多数问题，否则如果只用了部分，是体现不出CMP的优势的！还不如都不用！因为CMR连接了各种CMP，来达到数据之间关系的封装，如果局部采用了CMP，那么肯定会有缺口，这样导致CMP和JDBC混用是肯定会增加工作量的。
再者：如果说使用查询来解决CMP的内存征用问题，那么在这里得到的收益，在程序上还是得用“增加代码冗余”和“维护工作量”来填回去的！我觉得还是在原地踏步。除非是为了系统响应速度而这么做，要是为了这个目的的话还不若寻找其他提高速度的方法。这又违背了EJB的目标--“封装底层数据操作复杂性”。

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

那么是不是我可以在系统的大部分功能都用CMP封装数据了？
我这个系统估计内部员工用户大约15000，而且有部分内容是对外网公开的！特点是网页访问的集中度有时候很高（平时不多，但某些日子会固定有那么一两天会使近1/2的员工同时上来访问），表一共大约170张（也许没那么多，对核心的表的估计我不清楚），关联关系比较复杂，模块之间的调用也很频繁。按照这样的概念的话CMP估计会有150个左右！系统能不能受得了啊？我比较担心（当然这么多CMP中，有一些数据访问频度是很少的）！

1 如果访问的操作主要是查询的话，用JDBC+SQL比较好，我们现在就是采用这种模式。我们可以根据特定的数据库，对SQL语句进行优化，另外，还可以利用特定数据库的一些特性，来提供性能。
2 我觉得，如果你或者你的项目组中没有人对CMP非常熟悉的话，还是慎用CMP，不然项目可控性方面有些问题。

First,I wish you all have a wonder new year.
This is a interesting discussion, my comment is based on the following assumptions:
1) you indeed have a real project, otherwise the debate is waste of time
2) Main concern here is performance, you have over 7,500 concurrent users at peak, each user may work on some transactions that may involve access records from multiple tables

AppServer is the right choice but stay away from CMP, scalability is No.1 concern, you may also run into difficulty of managing the variety of queries due to the unpredictable nature of enterprise system. Last, even your developers may not like the sluggish deployment processing if all 150 tables are Entity Beans.

You probably still can archive the targeted performance using CMP, but I am pretty sure if you use WLS or WAS, very likely you have to get yourself deep into Vendors specific feature extension.

I can show you many large systems that is not using CMP, but not the other way. One HR system I helped to build is handling 15,000 data entry users during rush hours.

Cheers,
Jevang

象WEB下的信息系统都有一个数据列表页面，数据都事采用分页显示的，这种情况就不是一次查询大数据量的情况，我的系统基本都是这种情况，这样应该不会造成什么大的性能影响吧？？？

谢谢大家！
听取了大家的建议后，我决定不把设计的基础放在CMP上：
1，为了性能和系统的风险度，大部分情况下采用原始的“直接JDBC访问”方法实现；
2，而在以下特殊情况下采用CMP实现：a复杂关联关系，b频繁更新或者有很多并发更新，c需要对某些数据操作提供系统级别的集成功能；
3，另外，如果系统负荷情况有足够多的空间，可以把部分介于条件1和2之间的、并且相对独立一些的数据操作封装到CMP中去！

大家觉得如何（这好象抛弃了O/R Maping的方法，反朴归真了呵呵）？

另外：有没有人帮我看一下我帖子里后面提到的<dependent>的概念啊？这篇文章说是EJB2.0规范里有！但是我看了WebLogic的ejb-jar.XML的DTD文档，里面更本就没有。这是怎么回事啊？

个人意见：
必须用的时候就用，不必用的时候就不要用。先别用砖头砸我！:)
可以用的时候：
1.有事务控制的需求，特别是分布式的两阶段提交的事务；
2.系统部署分布在多个服务器上；
3.支持多种客户端和展现层，如要支持Swing和Web等；
4.有异步处理的需求；
5.想提高（BO）复用程度;
6.想控制安全特性到(BO)EJB上；
7.分布式系统需要提供服务并整合；
如果上边的条件具备一些，就考虑用EJB，能不用就不用。

其实CMP也不是万能的，性能好坏不说，它只提供了良好的弹性，但你的系统中一定要这样的功能吗？性能我认为绝对不如O/R mapping.

在J2EE模式中，提高系统的整体性能，读还是用Fast lane模式，操作数据就用EJB了。

不知道自己说了些什么，呵呵。其实我只同意你的2的部分看法。
现在可以扔砖头了。我逃！！

说EJB提供了可移植性，可配置是不可以移植的。晕...