Spring 3.0 与 Java EE 6.0

Spring 3.0 vs Java EE 6.0

提问by Jose Diaz

I'm confronted with a situation...

我面临着一个情况...

I've been asked to give an advise regarding which approach to take, in terms of Java EE development between Spring 3.0 and Java EE 6.0. I was, and still am, a promoter of Spring 2.5 over classic Java EE 5 development, specially with JBoss, I even migrated old apps to Spring and influenced the re-definition of the development policy here to include Spring specific APIs, and helped the development of a strategic plan to foster more lightweight solutions like Spring + Tomcat, instead of the heavier ones of JBoss, right now, we're using JBoss merely as a Web container, having what I call the "container inside the container paradox", that is, having Spring apps, with most of its APIs, running inside JBoss, So we're in the process of migrating to tomcat.

我被要求就 Spring 3.0 和 Java EE 6.0 之间的 Java EE 开发提供关于采用哪种方法的建议。我曾经是，现在仍然是 Spring 2.5 对经典 Java EE 5 开发的推动者，特别是 JBoss，我什至将旧应用程序迁移到 Spring 并影响了此处开发策略的重新定义以包含 Spring 特定的 API，并帮助制定战略计划以促进更轻量级的解决方案，例如 Spring + Tomcat，而不是较重的 JBoss，现在，我们仅将 JBoss 用作 Web 容器，具有我所说的“容器内的容器悖论”，也就是说，拥有 Spring 应用程序及其大部分 API，在 JBoss 中运行，因此我们正在迁移到 tomcat。

However, with the coming of Java EE 6.0 many features, that made Spring attractive at that time, easy deployment, less-coupling, even some sort of D.I, etc, seems to have been mimicked, in one way or the other. JSF 2.0, JPA 2.0, WebBeans, WebProfiles, etc.

然而，随着 Java EE 6.0 的到来，许多让 Spring 在当时很有吸引力的特性，容易部署，低耦合，甚至某种 DI 等，似乎都被以一种或另一种方式模仿了。JSF 2.0、JPA 2.0、WebBeans、WebProfiles 等。

So, the question goes...

那么，问题来了……

From your point of view, how safe, and logical, it is to continue to invest in a non-standard Java EE development framework like Spring given the new perspectives offered by Java EE 6.0?

在您看来，鉴于 Java EE 6.0 提供的新视角，继续投资于非标准 Java EE 开发框架（如 Spring）有多安全和合乎逻辑？

Can we talk about maybe 3 or 4 more years of Spring development, or do you recommend early adoption of Java EE 6.0 APIs and its practices?

我们能否再讨论 3 或 4 年的 Spring 开发，或者您是否建议尽早采用 Java EE 6.0 API 及其实践？

I'll appreciate any insights with this.

我将不胜感激对此的任何见解。

回答by Oliver Drotbohm

The crucial point IMHO is not the one of features. In that regard, Spring will always be ahead of JavaEE as it's natural for OpenSource VS. a Standard. So one fact is, that you get the new features much earlier with Spring that with JavaEE (e.g. container integration testing is a new feature in JavaEE 6 and has been available in Spring for ages).

恕我直言，关键点不是功能之一。在这方面，Spring 将永远领先于 JavaEE，因为它对 OpenSource VS 来说是很自然的。一个标准。所以一个事实是，使用 Spring 比使用 JavaEE 更早地获得新特性（例如，容器集成测试是 JavaEE 6 中的一项新特性，并且在 Spring 中已经存在多年）。

The most important point IMHO is the one of lifecycles for administration and development. When you choose JavaEE, you tie your programming model to your infrastructure. Usually app server vendors are not the fastest adopting new standard's versions (blame WebSphere, JBoss, what have you). So this means we probably won't see production ready, JavaEE 6 supporting products by the big vendors before end of the year.

恕我直言，最重要的一点是管理和开发的生命周期之一。当您选择 JavaEE 时，您将您的编程模型与您的基础设施联系起来。通常应用服务器供应商并不是采用新标准版本最快的（怪 WebSphere、JBoss，你有什么）。所以这意味着我们可能不会在年底之前看到大型供应商的 JavaEE 6 支持产品。

Even if that is the case then you still have to take the hurdle of your administration, IT department and budget controlling managers to be willing to upgrade to this shiny new version. Coming from this side, JavaEE 6 is not even an option to many shops. You can choose what ever you like to deploy your apps to? You wanna choose Glassfish for production? Go ahead, try. Most shops aren't in such a "comfortable" situation.

即使是这种情况，您仍然必须克服管理、IT 部门和预算控制经理的障碍，才愿意升级到这个闪亮的新版本。从这方面来看，JavaEE 6 甚至不是许多商店的选择。您可以选择将您的应用程序部署到什么位置？您想选择 Glassfish 进行生产吗？来吧，试试。大多数商店都没有处于这种“舒适”的状态。

Exactly contrary: Spring. Decoupled programming model from infrastructure. Go take current 3.0.x and use @Inject, JPA 2 and the like in your Tomcat or legacy application server.

恰恰相反：春天。将编程模型与基础设施分离。使用当前的 3.0.x 并@Inject在您的 Tomcat 或遗留应用程序服务器中使用、JPA 2 等。

回答by Will Hartung

If you're already a Spring shop, why bother switching? You're happy with it, it does what you want, it's actively developed, you're probably not looking to run outside of Tomcat any time soon, if ever, since Tomcat is very mature, and runs everywhere. So, any promise of portability that Java EE might suggest is right out the window.

如果您已经是 Spring 商店，何必换家呢？你对它很满意，它做你想做的，它正在积极开发，你可能不会很快在 Tomcat 之外运行，如果有的话，因为 Tomcat 非常成熟，并且到处运行。因此，Java EE 可能建议的任何可移植性承诺都已不复存在。

I see no reason to switch away from Spring.

我认为没有理由离开 Spring。

回答by Mateusz Dymczyk

Since Will and Oliver already said the most crucial stuff I'll only add that: "if it works and does the job done, then leave it alone!". "Newer" and "standardized" doesn't always equal "better", in fact it rarely does - new things are clunky and buggy and (that's the most important to me) not widely supported. If the rest of Java EE 6 is as "standardized" as JSF2.0 (and all the Rich/Ice/Prime/WhateverFaces), then believe me stick to Spring for now. A lot of companies stick to a bit older technologies for a reason (stability > *), Spring's been on the market for years and is well established.

既然 Will 和 Oliver 已经说了最关键的东西，我只会补充一点：“如果它有效并且完成了工作，那就别管它了！”。“更新”和“标准化”并不总是等于“更好”，事实上它很少如此——新事物笨重且有缺陷，而且（这对我来说最重要）没有得到广泛支持。如果 Java EE 6 的其余部分与 JSF2.0（以及所有 Rich/Ice/Prime/WhateverFaces）一样“标准化”，那么相信我现在坚持使用 Spring。许多公司出于某种原因（稳定性 > *）坚持使用一些较旧的技术，Spring 已经在市场上存在多年并且已经很成熟。

@Edit: Especially for @ymajoros: JSF (both 1.x and 2.x) is a flawed standard due to multiple reasons and is useful only in a handful of cases (i.e. when you are creating small, simple CRUD websites or when you're a Java EE enthusiast):

@Edit：特别是对于@ymajoros：由于多种原因，JSF（1.x 和 2.x）是一个有缺陷的标准，并且仅在少数情况下有用（即，当您创建小型、简单的 CRUD 网站时或'是 Java EE 爱好者）：

• creating new components is a pain in the ass. Since it is a component based framework I would assume it would make things easiernot harder. Currently I prefer to go with a JS+Java on the backend approach since it is actually easier for me to create components there. The only saving point of JSF is that there's a ton of components libraries. Problem starts when they don't work, you want to change something or create your own component.
• exception handling is a mess (or did something change in the past year or two?)
• JSF has problems with being too stateful - few bad decisions, one bad dev in your project and half of your app can be stateful and serialized.
• the UI part of the standard does not (or at least didn't when I wrote this answer) cover most collections from Java (in fact only decently covered data structure was a List).

• 创建新组件很麻烦。由于它是一个基于组件的框架，我认为它会使事情变得更容易而不是更难。目前我更喜欢在后端方法上使用 JS+Java，因为在那里创建组件实际上对我来说更容易。JSF 唯一的优点是有大量的组件库。当它们不起作用时，问题就开始了，您想更改某些内容或创建自己的组件。
• 异常处理一团糟（或者在过去的一两年里发生了什么变化？）
• JSF 存在状态太高的问题 - 很少有错误的决定，您的项目中有一个糟糕的开发人员以及您的应用程序的一半可以是有状态和序列化的。
• 标准的 UI 部分没有（或者至少在我写这个答案时没有）涵盖来自 Java 的大多数集合（实际上只有体面地涵盖的数据结构是列表）。

As for the standard which you are so fond of: did they at last somehow integrate JSF with JAX-RS? Because last I checked those specifications were totally separated even though you could make a lot of improvements. For instance why can't I annotate a method with @Path in my backing bean so it would be both handled by a REST request and a JSF request?

至于您非常喜欢的标准：他们最终是否以某种方式将 JSF 与 JAX-RS 集成在一起？因为上次我检查了那些规格是完全分开的，即使你可以做很多改进。例如，为什么我不能在我的支持 bean 中使用 @Path 注释一个方法，以便它同时由 REST 请求和 JSF 请求处理？

Maybe some (all?) of those issues are now fixed but when I wrote this answer they were but few among all the bad things about JSF and the standard in general.

也许这些问题中的一些（全部？）现在已经解决，但是当我写这个答案时，它们只是关于 JSF 和一般标准的所有坏事中的少数。

Currently if I want to create a very small, simple CRUD app I go with Play 2.0 (even though it is one huge anti-pattern) or something like RoR. When I want to create a large, "enterprise level" app then I grab a JS framework (like ExtJS) and a JS component library combine it with Java backend (and for instance Spring) and I do what I need without any overhead this so called standard would bring.

目前，如果我想创建一个非常小的、简单的 CRUD 应用程序，我会使用 Play 2.0（即使它是一个巨大的反模式）或类似 RoR 的东西。当我想创建一个大型的“企业级”应用程序时，我会使用一个 JS 框架（如 ExtJS）和一个 JS 组件库将它与 Java 后端（例如 Spring）结合起来，然后我做我需要的事情而没有任何开销，所以叫标准会带来。

Of course there are cool parts of JEE6 like JPA2, JAX-RS2, bean validation isn't all that bad. But using the whole standard stack only because they called it a "standard" (and as I mentioned above most of the specs don't even synergize) is, in my veryhumble opinion, just wrong.

当然，JEE6 也有一些很酷的部分，比如 JPA2、JAX-RS2，bean 验证也不是那么糟糕。但采用全标准堆栈仅仅是因为他们把它称为“标准”（正如我上面大部分规格的甚至不增效提到的）是，我非常愚见，错误的。

回答by Maarten Abbring

I think you will have noticed working with Spring makes you more productive than Java EE. I don't think they will ever be able to make the pig (Java EE) really fly. Java is a great language/platform, don't cripple it with Java EE. Why settle for 'some sort of dependancy injection', if you can today have Spring?

我想您会注意到，使用 Spring 比 Java EE 更高效。我认为他们永远无法让猪（Java EE）真正飞起来。Java 是一种很棒的语言/平台，不要用 Java EE 削弱它。如果您今天可以拥有 Spring，为什么要满足于“某种依赖注入”？