欢迎来到Java学习网!
设为首页 | 加入收藏
当前位置: 首页 > Java架构 > Hibernate >

Hibernate 之父 Gavin King建议开发者升级到 Java EE 6 平台,并指出了一些不愿意升级的观点其实是没有根据的。

  Java EE 6 发布后,我看到了很多反对升级到新平台的观点。这些反对观点大多是由 Tomcat / Jetty 以及一些开源框架(例如 Hibernate 与 Spring)的使用者提出。

  当然,选择非标准、开源技术有很多好处。另外,在 EE 6 中,你可以使用你感兴趣的开源框架,Servlet 3 与 CDI 可以无缝集成第三方框架。因此,没有理由不使用 EE 6。尽管如此,我还是看到有人说:

  升级到 EE 应用服务器很困难

  这似乎是具体组织的政治问题,而不是实际的技术问题。当然,升级服务器(例如 GlassFish 或 JBoss)是非常琐碎的任务。(升级第三方框架就更为痛苦了。)一些组织机构对服务器升级有着非常重量级的过程,而对于服务器内运行的框架的升级过程却没有如此重的过程控制。因此,对于开发团队来说,升级第三方框架反而更容易一些。

  我认为开发更有说服力、更好的过程才是最重要的,而不是放弃 Java EE。将你的应用运行在老旧、过时的服务器平台上存在很多风险,过程不应该鼓励这样的实践。

  但从实践角度看,几乎每一个人都准备最近就升级到 Servlet 3。无论你在使用 Tomcat、Jetty、JBoss、GlassFish、Resin、WebLogic、Oracle 还是 WebSphere,都意味着服务器的升级。这是一个升级到 EE 6 Web Profile 的绝好机会,黄金时机。

  EE 应用服务器太庞大了

  反对理由是 EE 服务器包含了很多(当前)使用不到的功能。反对者的论据通常涉及到了讨论 jar 包大小、Servlet 引擎+第三方框架与 EE 应用服务器所占用的磁盘空间大小的比较。其实,这样的论据是有问题的:

  讨论的磁盘占用、磁盘空间用 $ 衡量其实是微不足道的,并且应用 war 包比服务器安装包的大小重要得多,服务器其实包含了很多功能来尽量降低 war 的大小。

  另外,我认为最有说服力的是 Java EE 6 Web Profile 更本不庞大。一旦经过认证的 Web Profile 服务器投放市场,我们就可以在大的 EE 应用服务器与小的 Servlet 容器中间找到一个平衡点。

  糟糕的 J2EE 与 EJB2!

  随着 JCP 的标准化进程,这个问题其实早已不存在了:

  1.B2 从出现到现在已经 8 年了!它依然是你的最佳选择?

  2.不错的规范已经通过 JCP 不断的标准化而合并了,可以非常确定地使用其中一些规范。不过,JCP 在规范标准化上也不是100% 成功的。

  3.所有在 EE 6 平台上工作的人都讨厌 EJB2 与 J2EE。这就是为什么有人不断地加入到 JCP 来帮助修复这些问题。例如,Hibernate 的创始人,本文的作者。你真的想给他上一课关于 EJB2 的问题?:-)

  4.实体 Bean(Entity Beans)的人几乎现在都退休了!

  事实上,Java EE 6 Web Profile 已经足够用了。如果你不亲自尝试 Java EE 6,你是不能真正感受到 EE6 对开发的好处的。

  应用服务器可移植性太神秘了!

  真的吗?我们看到很多人将应用程序分割后部署于不同的应用服务器上?噢,我看到过,这意味着 100% 完美地进行应用程序 0 改变移植,一种柏拉图式的理想可移植性。我了解对于绝对真理与柏拉图式理想的弱点,不过还是让我们先看看例子。

  这是一个非常典型的可移植性问题视图:

  9% 的代码,85 % 的外部元数据在不同服务器平台上完全兼容,剩下 1% 与 15% 能够适当进行分割

  0% 的代码,80% 的外部元数据绑定在了非标准、单一厂商的容器体系结构上

  当我划分这些点时,我突然想将本节主题从 应用服务器可移植性太神秘了 改成 我根本不在乎容器可移植性。主题改变的想法印证了服务器可移植性问题的确存在,并且这对于很多组织机构来说非常有用。

  我一直想看到非 EE 6 技术维护者对 EE 6 真实的评论。上文中提到的一些论据不是来自真实世界的,所以很难引发 EE 平台上应用开发实际技术问题的讨论。JCP 最近一轮规范似乎已经离开了反 EE 阵营(暂时性离开?),但缺乏成功的事实支撑。
 

    相关教程
    推荐内容