EJB3，我们究竟得到了什么（4）

最新推荐文章于 2020-05-31 10:55:32 发布

guxinhua

最新推荐文章于 2020-05-31 10:55:32 发布

阅读量1.9k

点赞数

分类专栏： EJB3/J2EE1.5 文章标签： ejb hibernate session manager dao 测试

本文链接：https://blog.csdn.net/guxinhua/article/details/569028

版权

EJB3/J2EE1.5 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

<四>玩花样

从四人帮整理的设计花式开始，花式被认为是一种可重复利用的，由经验得来的比较好解决常见问题的方法。J2EE应用的花式很多，也因为它麻烦最多，在各个层上都有，其作用也五花八门，清晰化构架，提高系统性能等等，但它们基本不是去解决某个特定逻辑问题，而是带着强烈的结构花式的味道。Sun推荐的Core J2EE Pattern套路成了一个花式系统，这些花式的产生，基于某些特定的原则和考虑，而一些原则和考虑也是因为EJB的不足而引起。下面我举一两个简单的例子说明。

Oracle的Raghu Kodali的演讲:EJB2.1.vs.EJB3性能比较，很明显地在性能方面强调了EJB3的好处。我不想再重复他的观点，只是从他的演讲引出EJB 开发的老朋友花式。性能比较当然是响应时间和吞吐量，注意到他测试的例子有两个花式，DTO和Session Facade。我也从DTO讲起。很明显，DTO是第一个在EJB3中被灭的花式，原因很简单，EJB3的entity可以被线性话，这个在轻量级容器中已经被讨论过，在Hibernate In Action一书里，DTO被视为是多此一举的东西，因为可以把一个线性话的POJO看作DTO来减少round trip。(在此书中的DTO讨论中，我们再次看到有些概念的空洞和片面。)在 Raghu比较用DTO和不用DTO的EJB3的结果中，我们看到，在250个模拟用户开始，EJB3开始显示微弱的性能的优势，曲线暗示着负载越多，性能越好。所以我在他的结论上加一句，EJB3的Entity不但性能更好点，而且不用重复代码。

在使用Session Facade的测试中，我很惊讶地看到不管是交易率还是平均响应时间，从25个用户开始EJB3就有明显的优势。但是，我马上就发现这些性能的提升基本是基于一个大换血的持久层，如果EJB3用同一个花式来和EJB2.1比拼，其优势完全靠一个更全新的透明持久方案，这也暴露了原来CMP和所用的CMR的弊端，它们不但性能差而且限制多，拿CMR来讲，只能用双向关系。

其他的花式例如DAO,BD等等在EJB3仍然是有意义的，也是轻容器经常会用到的。在轻容器中我们可能谈得更多的是交易相关的设计方案。我说他们是方案，是因为花式认证需要在社团里通过三个以上的系统解决问题的考核，即rule of three。而这些方案最初只在轻容器中出现，我想在不久的将来，他们可能是EJB开发者的口头禅: Entity Manager per request; Entity manager-per-request-with-detached-objects;Entity manager-per-application-transaction;Entity manager-per-operation Anti-pattern; Entity manager-per-user-session Anti-pattern.............