我遇到了一个情况…
我曾被要求就采用哪种方法提供建议,就Spring 3.0和Java EE 6.0之间的Java EE开发而言。我曾经是,现在仍然是Spring 2.5的推动者,特别是在JBoss上,是经典Java EE 5开发的推动者,我什至将旧应用迁移到Spring,并影响了此处对开发策略的重新定义,以包括Spring特定的API,并帮助制定战略计划以培育更轻巧的解决方案,例如Spring + Tomcat,而不是笨重的JBoss,现在,我们只是将JBoss用作Web容器,而我称之为“容器悖论中的容器”,也就是说,在JBoss中运行具有大多数API的Spring应用程序,因此我们正在迁移到tomcat。
但是,随着Java EE 6.0的到来,许多功能使当时的Spring变得有吸引力,易于部署,耦合较少,甚至某种形式的DI等,似乎都以某种方式被模仿了。JSF 2.0,JPA 2.0,WebBeans,WebProfiles等
所以问题来了…
从你的角度来看,鉴于Java EE 6.0提供的新观点,继续投资像Spring这样的非标准Java EE开发框架是多么安全和合理?
我们能否谈谈Spring开发的3年或4年,还是建议你尽早采用Java EE 6.0 API及其实践?
我将不胜感激。
在这方面,由于OpenSource VS很自然,Spring将始终领先于JavaEE。一个标准。因此,一个事实是,与JavaEE相比,Spring可以更早地获得新功能(例如,容器集成测试是JavaEE 6中的一项新功能,并且已经在Spring中使用了很长时间)。
恕我直言,最重要的一点是管理和开发的生命周期之一。当选择JavaEE时,会将编程模型绑定到基础架构。通常,应用服务器供应商并不是采用新标准最快的版本(责备WebSphere,JBoss,你拥有什么)。因此,这意味着我们可能不会在年底之前看到生产准备就绪,大厂商支持JavaEE 6的产品。
即使是这种情况,你仍然必须克服管理,IT部门和预算控制经理的障碍,才愿意升级到此闪亮的新版本。从这一方面来看,JavaEE 6甚至不是许多商店的选择。你可以选择将应用程序部署到哪个平台?你想选择Glassfish生产吗?继续尝试。大多数商店都不是那么“舒适”。
恰恰相反:spring。将编程模型与基础架构分离。使用当前的3.0.x并@Inject
在Tomcat或旧版应用程序服务器中使用,JPA 2等。