O
oskiller
Unregistered / Unconfirmed
GUEST, unregistred user!
好久没来，居然这么热闹啊？哈哈。
在Java的世界，OR mapping一直就是最受关注的技术，目前也是和.net战斗的焦点。
看看数据访问技术在Java世界走过的路，很有趣。
1、最初是JDBC，这个我想大家都没有异议吧？虽然它很成功的统一了数据访问层的界面，但是
它不是面向对象的。这并不奇怪，虽然它是用OO的JAVA语言定义的，但是这个数据访问层不可避
免的是面向关系的语义。因为它仅仅是个底层接口。其后针对这样的问题有不少解决方案。象
DAO这样的J2EE design pattern就是一列。但也只是责任的转移，并没有根本地解决这个问题。
2、再之后就是EJB中的EntityBean了，它在一定程度上解决了“将面向关系的语义改进为面向对
象的语义”的问题，它也很成功。但其致命的缺点就是由于最初的设计失误，使得其承担了本来
不应该由它具备的特性，导致的结果就是性能不足。当然我不是再攻击EntityBean技术，它在很
多时候还是适用的。特别是在大多数数据访问操作都是针对同样数据时，由于应用服务器的高速
缓冲能力，此时的性能还是相当强悍的。
我之所以说是设计失误有以下的原因:
由于最初EJB的设计目标就是对Bean按照职责进行分类，并且使其具备同样的对象模型，并为
client提供同样的视图。特别是后者，导致了设计者们不得不让EntityBean具备了过多的特性。
看看EntityBean的设计目标:
1)提供一个标准的方式以持久化你的domain model
2)封装持久化机制，（也就是完成OR mapping)
3)为了和SessionBean保持一致，EntityBean必须是暴露到网络上的分布式对象，可从任何地方访问。
4)同样是为了和SessionBean保持一致，它必须是具备事务特性的对象。
ok，很明显上述的第三和第四个目标是根本没有必要的。我想绝大多数人都会用SessionBean来
包装EntityBean，也就是client只应访问SessionBean调用企业逻辑，而EntityBean只应由SessionBean
来访问。那么为什么要把EntityBean暴露为网络上的分布式对象呢？另外既然SessionBean包装了
EntityBean ，那么后者是否还有必要具备事务特性呢？显然不必要。然而正是由于3)4)两个设计
目标极大的影响了性能。
为什么会有这样的设计目标？原因就是要保持SessionBean和EntityBean的一致性。对于最初的
设计者而言，他们的想法是:对于每个Bean而言，它应该感到有一个专有的容器为它提供服务，该
容器里也只有它一个Bean，所以它应该暴露为分布式对象对外提供调用接口。所以Bean与Bean之间
完全独立，它可以认为任何其它的Bean都是在另一个服务器上的另一个容器中运行(网络透明/位置无关)
这样的设计我想也是为了强大的可伸缩性能力，因而也使得真正的完全集群，均衡负载成为可能。
付出的代价就是性能。但是EntityBean是否也应该具备这样的特性呢？回到现实世界来说的话，
完全没有必要！
(btw:目前的EJB规范，特别2.x规范针对这样的问题，极大地强化了CMP能力，并引入了Local interface
甚至倡导人们使用local interface，呵呵，java世界技术的进步完全是为了实用，可不是为了广告
另外比较有趣的是:如果大家对JDO也比较了解的话，会发现目前的EntityBean技术极大地借鉴了JDO的思想
甚至实现手段)
3、数据访问技术第三阶段(目前)的发展就是JDO了。我认为它将是阶段性的终点。
JDO可以说是真正地完成了OR mapping。当然我是说它的设计思想，第一版的JDO规范还不完善。
它给予人们的能力就是:一切都是对象，你只需要与对象打交道。
关于JDO有一句著名的话:
Java Data Objects seem to be what Entity Beans should have been.
当然这句话还很有争议。有兴趣的兄弟去theServerSide搜索一下。
想想看,很简单的纯粹的java class就能完成标准的持久化访问，并且我们根本不需要关心其下
的持久化机制，而且性能强劲。不许要裹脚布一般又臭又长的部署描述器，不需要大量的JNDI
lookup查找domain model类。我们直接与封装完好的domain model 对象打交道。JDO自动地为
我们做到了这一切。
由于目前小弟也在学JDO，所以无法深入讨论。不过可以提点建议。
对于学习用的JDO实现，Libelis的JDO实现比较标准，但是只是用于教学用的。你别指望将来
在现实世界中使用它。另外一个是Apache的obj。大家想必知道Apache Jakarta工程在Java世
界的分量吧？我目前也在用它。它的优点就是体系结构非常清晰，容易理解，如果各位剖析
一下它的源代码就知道了，而且是真正为了现实世界的使用而创建的。第三个就是Castor了，
这个玩意儿让我想起原来曹晓刚在哪篇帖子里面提到的:
数据库模式 ——Java Class——XML Scheme
之间的mapping，呵呵，Castor就是专门用来做这个的。而且做得相当的好，只是由于Castor
出现得比JDO规范早得多，所以目前对JDO规范的支持还不完整。它和obj相比，体系结构不是
那么清晰，所以说要让它完善支持JDO规范，任务即使不说艰巨，还是有一定难度。
最后，我也是Jdo的初学者，上面的观点很可能有不妥之处，期望大家多多交流。
在Java的世界，OR mapping一直就是最受关注的技术，目前也是和.net战斗的焦点。
看看数据访问技术在Java世界走过的路，很有趣。
1、最初是JDBC，这个我想大家都没有异议吧？虽然它很成功的统一了数据访问层的界面，但是
它不是面向对象的。这并不奇怪，虽然它是用OO的JAVA语言定义的，但是这个数据访问层不可避
免的是面向关系的语义。因为它仅仅是个底层接口。其后针对这样的问题有不少解决方案。象
DAO这样的J2EE design pattern就是一列。但也只是责任的转移，并没有根本地解决这个问题。
2、再之后就是EJB中的EntityBean了，它在一定程度上解决了“将面向关系的语义改进为面向对
象的语义”的问题，它也很成功。但其致命的缺点就是由于最初的设计失误，使得其承担了本来
不应该由它具备的特性，导致的结果就是性能不足。当然我不是再攻击EntityBean技术，它在很
多时候还是适用的。特别是在大多数数据访问操作都是针对同样数据时，由于应用服务器的高速
缓冲能力，此时的性能还是相当强悍的。
我之所以说是设计失误有以下的原因:
由于最初EJB的设计目标就是对Bean按照职责进行分类，并且使其具备同样的对象模型，并为
client提供同样的视图。特别是后者，导致了设计者们不得不让EntityBean具备了过多的特性。
看看EntityBean的设计目标:
1)提供一个标准的方式以持久化你的domain model
2)封装持久化机制，（也就是完成OR mapping)
3)为了和SessionBean保持一致，EntityBean必须是暴露到网络上的分布式对象，可从任何地方访问。
4)同样是为了和SessionBean保持一致，它必须是具备事务特性的对象。
ok，很明显上述的第三和第四个目标是根本没有必要的。我想绝大多数人都会用SessionBean来
包装EntityBean，也就是client只应访问SessionBean调用企业逻辑，而EntityBean只应由SessionBean
来访问。那么为什么要把EntityBean暴露为网络上的分布式对象呢？另外既然SessionBean包装了
EntityBean ，那么后者是否还有必要具备事务特性呢？显然不必要。然而正是由于3)4)两个设计
目标极大的影响了性能。
为什么会有这样的设计目标？原因就是要保持SessionBean和EntityBean的一致性。对于最初的
设计者而言，他们的想法是:对于每个Bean而言，它应该感到有一个专有的容器为它提供服务，该
容器里也只有它一个Bean，所以它应该暴露为分布式对象对外提供调用接口。所以Bean与Bean之间
完全独立，它可以认为任何其它的Bean都是在另一个服务器上的另一个容器中运行(网络透明/位置无关)
这样的设计我想也是为了强大的可伸缩性能力，因而也使得真正的完全集群，均衡负载成为可能。
付出的代价就是性能。但是EntityBean是否也应该具备这样的特性呢？回到现实世界来说的话，
完全没有必要！
(btw:目前的EJB规范，特别2.x规范针对这样的问题，极大地强化了CMP能力，并引入了Local interface
甚至倡导人们使用local interface，呵呵，java世界技术的进步完全是为了实用，可不是为了广告
另外比较有趣的是:如果大家对JDO也比较了解的话，会发现目前的EntityBean技术极大地借鉴了JDO的思想
甚至实现手段)
3、数据访问技术第三阶段(目前)的发展就是JDO了。我认为它将是阶段性的终点。
JDO可以说是真正地完成了OR mapping。当然我是说它的设计思想，第一版的JDO规范还不完善。
它给予人们的能力就是:一切都是对象，你只需要与对象打交道。
关于JDO有一句著名的话:
Java Data Objects seem to be what Entity Beans should have been.
当然这句话还很有争议。有兴趣的兄弟去theServerSide搜索一下。
想想看,很简单的纯粹的java class就能完成标准的持久化访问，并且我们根本不需要关心其下
的持久化机制，而且性能强劲。不许要裹脚布一般又臭又长的部署描述器，不需要大量的JNDI
lookup查找domain model类。我们直接与封装完好的domain model 对象打交道。JDO自动地为
我们做到了这一切。
由于目前小弟也在学JDO，所以无法深入讨论。不过可以提点建议。
对于学习用的JDO实现，Libelis的JDO实现比较标准，但是只是用于教学用的。你别指望将来
在现实世界中使用它。另外一个是Apache的obj。大家想必知道Apache Jakarta工程在Java世
界的分量吧？我目前也在用它。它的优点就是体系结构非常清晰，容易理解，如果各位剖析
一下它的源代码就知道了，而且是真正为了现实世界的使用而创建的。第三个就是Castor了，
这个玩意儿让我想起原来曹晓刚在哪篇帖子里面提到的:
数据库模式 ——Java Class——XML Scheme
之间的mapping，呵呵，Castor就是专门用来做这个的。而且做得相当的好，只是由于Castor
出现得比JDO规范早得多，所以目前对JDO规范的支持还不完整。它和obj相比，体系结构不是
那么清晰，所以说要让它完善支持JDO规范，任务即使不说艰巨，还是有一定难度。
最后，我也是Jdo的初学者，上面的观点很可能有不妥之处，期望大家多多交流。