【IT168 专稿】最近我和我的同事在一起讨论下一期的选题的范围、轮廓和思想的时候，我注意到他们对EJB 3.0非常推崇。其中一位“高级”编辑直截了当的告诉我：“不要写Hibernate或Spring了，EJB 3.0都出来了，现在开始写写这个标准吧”。

标准禁锢JEE

作为一个精通企业架构和开发的人，我明显感觉到了这种不可避免的推动力，那就是埋葬Hibernate和Spring吧，开始宣传EJB 3.0！而在我看来，这无疑等于把一些非常好的工具扔到臭水沟里，而这只是为了继续维持Sun的帝国梦和Java标准组织（JCP）不容质疑的领导地位。但是从企业的视角来看，企业在解决轻量级复合实体模式中的DAO问题的时候，它不在乎你是使用EJB 3.0、还是使用Spring或者甚至是Hibernate，对于设计师来说，全都是JEE。

假若JEE要想作为一个平台继续生存下去，我们必须停止把他作为一套Java标准组织（JCP）的相关技术来教给大家，因为它通常是非常复杂的，正如在Glassfish项目相关实施中体现的那样，或许Sun会被赞扬。我相信，要进入JEE 5时代并且掘弃在EJB 1.和EJB 2.x给开发者带来的糟粕之处，最好的途径就是把JEE作为一套完整的思想模式教给大家，把它们从不同厂家的实施方案中抽象提取出来，并作为企业领域最佳的实践操作指南。

试想一下用AJAX的思想来解决JEE问题，AJAX不是任何某一家公司的技术，甚至它连个实施指南都没有。你可以自由的使用你想要的后台，使用任何你想要的持久性设计，甚至实施你自己的异步回调（call－back）。AJAX最成功的地方是最好的实践和模式，开发者可以使用它们来创建引人注目的Web客户端。为什么不让JEE更像AJAX呢？为什么在JEE模式还没有抛弃我们的时候，我们要朝着这些相关JCP技术发展呢？”

当我自己创建UML模型或看别的UML模型的时候，在它们的并不优雅的组件架构中，看到许多许多业务对象（BO）模式、DAO模式、Domain Stores，我看到了JEE的特点：孤立、粗糙的对象（简单的对象）、安全性和独立性。那么，一个公司A实现其业务逻辑的途径可能有两者：可以采取在其JBoss应用服务器中插入一个嵌入式EJB3.0的方式，或者在其JBoss应用服务器中使用嵌入的Spring，那么这两者之间有什么区别吗？假若我是一个使用众多业务托管来访问企业应用的核心服务的Web开发者或应用程序开发者，上面不同的选择对我有什么影响吗？假若我是一个企业开发者，架构师已经完成了他的工作－从业务对象中抽象提取出DAO和相关对象，因此我可以迅速的投入并完成从Spring到EJB 3.0的转换。这就是在EJB1.X和早期EJB2.X时代的DAO模式的要点所在。因此当EJB 3.0这个神秘的东西已经做好快速且广泛的部署的时候，就把DAO/JDBC搁到一边。