对CMP应正确看待，难道真的一无是处？

所以大家使用CMP时，请一定正确使用粒度问题，在这一点上，还请Banq 赐教.我还没有开始研究petstore的代码， 垦请Banq具体说一下， 例如： 一张表与一个CMP对应 不好的话，应如何去重构呢？谢谢！

如果不是，那是如何实现的呢？

DependentObject不是关联的CMP对象。

我只是自已把自已问住了，如果DependentObject不用JDBC SQL实现，那如何利用EJB中O/R Mapping 的优势， 如果DependentObject不用JDBC SQL实现,那还要CMP做接口类于嘛?

如果DependentObject不用JDBC SQL实现，那如何利用EJB中O/R Mapping 的优势? 如果DependentObject用JDBC SQL实现,那还要Aggregate EntityBean做什么?

如何在CMP中实现一Bean对一表的重构?

关于EJB Entity Bean、JDBC 以及Hibernate选择，可以看看老外这篇文章：

http://www.meagle.com:8080/hibernate.jsp

用 Session Bean + DAO + Hibernate 来取代 Session Bean + Entity Bean，不但能够极大降低软件设计难度，软件开发难度，软件调试难度和软件部署难度，而且还可以提高允许效率，降低硬件要求。

不要把EB直接拿来和Hibernate做比较，两者不是一个范畴的东西，而应该整体比较两种方案：

Session Bean + DAO + Hibernate

Session Bean + Entity Bean

我找不出来第二方案有哪怕一点方面能够比第一方案好的。

我提的问题在EJB实现中的确很难说清楚，不过我个人认为：Sun提出的aggregate entitybean模式仅仅是对BMP说的，如果用在CMP中，就自相矛盾了。

总的来说，CMP局限性太多，因此才有这么多J2EE Core Patterns 来解决很多EJB中的性能问题。CMR也不好，越多的CMP，越差的性能，而且CMP还不能脱离数据库中表的外键使用。

" 一张表与一个CMP对应 不好的话，应如何去重构呢？"

使用CMR很方便的前提条件是对数据表设计有限制的。

如果使用CMR，那么就将两个表的对应关系单独设计成一张表，如：

CREATE TABLE customer (
  id varchar(50) NOT NULL default '',
  firstName varchar(50) default '',
  lastName varchar(50) default '',
  UNIQUE KEY customerID (id)
) TYPE=InnoDB;
# --------------

CREATE TABLE address (
  addressID varchar(50) NOT NULL default '0',
  street varchar(50) default '',
  city varchar(50) default '',
  zip varchar(50) default '',
  state varchar(50) default '',
  customerID varchar(50) default '',
  PRIMARY KEY  (addressID),
  KEY customerID (customerID)
) TYPE=InnoDB;

<p>

这两种表是一对多关系，这将两个表一对多关系设计在address一个表中，这是过去我们统计喜欢作的，但是使用CMR时，最后单独设计一张表，如下：

CREATE TABLE customer (
  id varchar(50) NOT NULL default '',
  addressID varchar(50) NOT NULL default '0',
  KEY addrssID (addressID),
  UNIQUE KEY customerID (id)
) TYPE=InnoDB;


这样做有两个好处：
1.符合CMP的CMR内部实现机制，性能好；
2.方便关系重整。
<p>

为什么“J2EE Core Patterns 来解决很多EJB中的性能”？

因为EJB是个框架组件技术，这种技术在以前一般人没有碰到过，把它当做API使用，API没有框架那样对应用继承介入那么深入。

要想用好EJB，必须了解EJB机制，使自己的应用系统符合EJB本身的节拍，可以说是符合客观规律吧，不再象以前编程那样，由程序员天马行空，想怎么做就怎么做，使用EJB就必须使用这些模式，按照这个框架做，否则违反规律必导致性能降低。

这些都是出于保证项目质量、实现重用性角度考虑的，所以喜欢自由，有个性的程序员是不喜欢EJB的。

但是在大规模生产中，我们更需要的是规则和稳定易懂的程序代码。这已经谈开去了。

总之，EJB不是API，是框架，用框架就是要有限制，这种限制是靠设计模式来实现的。这样J2EE项目的架构设计就非常重要，这些都是架构设计的内容。

Hibernate是JDBC和实体Bean之间的一个选择，虽然它在开发上与图形化CMP开发相比，节省了一些setXXX字段的编程工作量，但是Hibernate和CMP还是不同重要级别的技术。

Hibernate是替代Jdbc或连接池直接操作的技术，现在还有人津津乐道在研究JDBC 3.0的，象JDBC这样低层的技术除了Hibernate这样的产品研究者比较关注以外，对于一般应用者已经没有价值，这在研究方向上就发生了问题，在J2ee领域，后人总是不断站在前人的框架或层结构基础上的，就象使用Html已经没有必要知道Windows的图形API一样，J2EE领域现在关心的是如何软件如何最大重用，如何划分更细腻的层次，Hibernate无疑是持久层一项好的技术。

Struts+Hibernate确实很诱人，Struts将难以对象化的表现层实现了对象封装，其中ActionForm实际是VO变种，而持久层Hibernate输入输出参数都是VO，这样原来两个

很难实现对象化的层次被对象化了，确实是一个令人激动的事情，以后再有J2EE初学者，就要告诉它们，你们可以不学JDBC这些低层的技术了，直接从Hibernate和Struts

开始学吧，他们会觉得J2EE不再那么难了，可惜我们这些入道早点的“前辈”就要不断煎受取舍的痛苦了。

当然，Struts_Hibernate架构中，没有提供层次来防止很重要的业务逻辑层，因为这一般是由EJB的Sesssion Bean来完成，当然，也可以由

Web层的javaBeans来实现，如同OFbiz, Jive那样做一样，但是对象池等缓冲性能优化、事务锁机制、集群分布式技术都要自己实现，这些当然没有

由EJB容器实现的Session Bean来得干净，而CMP虽然不是一种O/R技术，但是作为由容器实现的技术和Session Bean的标准结合，因此我愿意采取

以下这样的技术：

Struts+ EJB Session Bean  ---> CMP或BMP （重要数据、在有一对多关系或多对一关系时首选）
                           |--> Hibernate （替代以前的DAO技术中JDBC SQL直接读操作，当然性能要求更高，直接采取JDBC）
<p>

把一对多，多对多的关系用一个关联表来处理的确是个好办法，不过我还是要仔细想想。

<<这样做有两个好处：

<<1.符合CMP的CMR内部实现机制，性能好；

<<2.方便关系重整。

1。我想不仅关联表对CMR有性能上的改善，而且对一些数据库里join 有很多外键的表的时候，性能也会提高。

2。关联表使持久层对所有的表和各种关系都同样对待，简化开发与重构。

由此我们可以探讨一下引入关联表的优势.