我现在开始一个新项目。我必须选择技术。我需要一些轻便的东西，所以没有 EJB 或 Seam。另一方面，我需要 JPA（休眠或替代）和带有 IceFaces 的 JSF。
你认为在 Tomcat 上部署 Spring 3 这样的堆栈是一个不错的选择吗？还是 Java EE 6 Web 应用程序会更好？恐怕 Java EE 6 是一种新技术，还没有很好的文档记录。Tomcat 似乎比 Glassfish 3 更容易维护。
你怎么看？你有什么经验吗？
问问题
39913 次
16 回答
101
我需要一些轻便的东西，所以没有 EJB 或 Seam。
您愿意解释一下自 EJB3 以来是什么让 EJB 变得如此繁重？您是否意识到我们不再是 2004 年了？我真的很想阅读您对光的定义和您的论点（我会很高兴地更新我的答案，因为我很确定我会有一些可靠的话要说）。
另一方面，我需要 JPA（休眠或替代）和带有 IceFaces 的 JSF。
Java EE 6 Web Profile 包括 JSF 2.0、JPA 2.0、Bean Validation、EJB 3.1 Lite、CDI，... 将是完美的，您可以使用GlassFish v3 Web Profile运行使用 Java EE 6 Web Profile 构建的应用程序.
您认为在 Tomcat 上部署 Spring 3 上的此类堆栈是一个不错的选择吗？还是 Java EE 6 Web 应用程序会更好？
好吧，我喜欢在非专有平台（Java EE）而不是专有容器（Spring）上运行我的代码的想法。而且我认为 Java EE 6 已经足够好（这是一个委婉说法，EJB 3.1 (Lite)、JPA 2.0、JSF 2.0、CDI 踢屁股）。请注意，我是一个 JSF 怀疑论者，但我再看一眼，发现带有 CDI 的 JSF 2.0 是如此不同，以至于我什至无法比较。如果你没有看过 CDI，让我告诉你它很震撼。
恐怕 Java EE 6 是一种新技术，还没有很好的文档记录。
在我看来，Java EE 的文档记录得很好。这听起来像是免费索赔。而且，不管你信不信，我开始发现 Spring 变得复杂，而 Java EE 变得更简单。
Tomcat 似乎比 Glassfish 3 更容易维护。
你尝试过什么吗？你有遇到什么特别的问题吗？同样，这听起来像是免费索赔。
于 2010-03-25T04:19:15.863 回答
34
我没有用过JavaEE6。
但是，JavaEE 和 EJB 的所有先前版本都对我造成了严重打击，以至于在它确立自己作为事实上的标准，而不仅仅是法律标准之前，我不会相信它。现在，Spring 仍然是事实上的标准。
骗我，是你可耻。骗我两次，真丢人。骗我三遍，EJB。
有些人会声称 Spring 是专有的。我会争辩说，JavaEE 规范的供应商实现同样是专有的，如果不是更多的话。
我最近经历了一次重大转变，将一堆 Java 应用程序从 JBoss 迁移到 Weblogic。所有 Spring/Hibernate 应用程序都进行了零修改移植，因为它们内置了所需的所有库。所有使用 JPA、EJB 和 JSF 的应用程序移植起来都是一场灾难。应用服务器之间对 JPA、EJB 和 JSF 解释的细微差异导致了各种令人讨厌的错误，这些错误需要很长时间才能修复。甚至像 JNDI 命名这样简单的事情在 AppServer 之间也是完全不同的。
Spring是一个实现。JavaEE 是一个规范。这是一个巨大的差异。如果规范是 100% 密封的，并且在供应商实施该规范的方式上绝对没有回旋余地，我更愿意使用规范。但 JavaEE 规范从未如此。也许JavaEE6更密封？我不知道。您可以在 WAR 中打包的越多，对 AppServer 库的依赖越少，您的应用程序的可移植性就越高，这毕竟是我使用 Java 而不是 Dot-NET 的原因。
即使规范是无懈可击的，如果能够升级应用服务器而不必升级我所有应用程序中的所有技术堆栈，那将是一件好事。如果我想从 JBoss 4.2 升级到 JBoss 7.0，我必须考虑更新版本的 JSF 对我所有应用程序的影响。我不必考虑对我的 Spring-MVC（或 Struts）应用程序的影响。
于 2011-08-11T14:43:46.907 回答
23
没关系。Java EE 6 已经足够好，并且由于那里的配置文件，它并不“重” - 您将只使用 Web 配置文件。
就个人而言，我更喜欢春天。但是我已经没有反对 Java EE 6 的合理论据了 :)
（正如评论提醒我的那样 - 您可能想尝试RichFaces以及ICEfaces和/或PrimeFaces - 取决于您需要的组件）。
于 2010-03-23T11:12:15.493 回答
17
最近，我的一项客户任务涉及评估 Spring Stack Vs Custom framework stack Vs a Java EE Standards。经过一个月的评估和原型设计，我不仅对 Java EE 6 的特性集感到高兴，而且让我大吃一惊。对于 2011 年及以后的任何新“企业”项目架构，我会选择 Java EE 6 和潜在的扩展，如 Seam 3 或即将推出的 Apache JSR299 扩展项目。Java EE 6 架构经过精简，并融合了过去几年中发展起来的众多开源理念中的精华。
考虑以下开箱即用的功能：事件管理、上下文和 DI、拦截器、装饰器、RESTful Web 服务、使用可嵌入容器的集成测试、安全性等等。
我的大部分结果都发布在我的博客中，解释了您可能会发现有用的 Java EE 6 的关键概念。
当然，选择框架并没有硬性规定。对于不需要丰富的会话会话状态的更简单的“网站”，Java EE 6 可能会非常臃肿。您不妨选择 Grails 或 Play！框架。但是对于会话式 Web 应用程序，我找不到更好的论据来说明为什么 Java EE 6 不适合。
于 2011-04-26T19:07:10.567 回答
15
现在，经过一段时间，我对堆栈有了经验：
- Java EE 5 + Seam + GraniteDS + Flex
- Spring 3 + Vaadin（在 GWT 上）
- Spring 3 + JSF 2.0 (PrimeFaces)
我的结论是：
- Spring 3 比 Seam（几乎是 Java EE 6）简单得多，并且可以在 Tomcat 和 Jetty 上运行！（使用 maven 插件进行开发的 Jetty 是一个宝藏）。
- 我喜欢 Flex（我实际上是一名 Flex 开发人员，所以我有偏见），如果你需要丰富的界面并且可以购买 FlashBuilder 使用它，但使用这个 Spring + GraniteDS 或 BlazeDs 后端。如果您不能购买 FlashBuilder，请不要浪费您的时间。
- 瓦丁太棒了！开发过程比 Flex 简单，但您可以轻松创建丰富的应用程序，而不会出现 HTML 混乱。你不会写一个单一的 JS 行。你只需要一些 CSS（在 Flex 中你也需要它）。因此，如果您的应用程序界面将表现得像桌面应用程序，而您不能（或不想）使用 Flex - 请使用 Vaadin。警告！Vaadin 对浏览器的 JS 开销很大。
- 如果您创建更简单的类似网站的应用程序，请使用 JSF2.0（使用上面的 spring 后端）。您需要与 HTML 作斗争（我讨厌它），并且创建丰富的界面将比 Vaadin 更难（尤其是布局）。您将获得适用于较慢浏览器/计算机的轻量级 HTML。我喜欢 PrimeFaces - 它简单且有据可查。第二名是IceFaces
- 如果您创建一个需要将生命放入 HTML 的网站（不是 Web 应用程序）（而不是创建适合浏览器的企业应用程序），请使用 Wicket（如果您更喜欢基于组件，拉取态度）或 SpringMVC（如果您更喜欢基于模板，推态度）或只是使用播放！框架。请记住，创建丰富的基于数据的组件要困难得多，但您可以控制 html 的每个标签（您的 HTML/图形设计师会喜欢它）
于 2010-11-04T10:46:04.637 回答
8
阅读 Adam Bien 的企业 Java 的未来 ...清晰（Java EE 有/没有 Spring 和 Vice Versa），包括获得硬币两面的评论。我会选择 Spring 有几个原因，以下是其中之一（复制帖子中的评论之一）
'我不确定你说的是哪个 Java EE 6 服务器。有 Glassfish 认证和 TMAX JEUS。WebSphere、WebLogic、JBoss 等的 Java EE 6 兼容版本投入生产并可以用于实际应用程序需要相当长的时间（阅读：数年）。Spring 3 只需要 Java 1.5 和 J2EE 1.4，因此可以在几乎所有环境中轻松使用'
于 2010-03-23T12:14:21.493 回答
8
我的观点是基于其他人没有提到的事情，即我工作中的代码往往可以存活数十年（字面意思），因此维护对我们来说非常重要。维护我们自己的代码和我们使用的库。我们控制我们自己的代码，但我们使用的库在上述几十年或更长时间内由其他人维护符合我们的利益。
长话短说，我得出的结论是，实现这一目标的最佳方法是使用 Sun 规范的开源实现一直到原始 JVM。
在开源实现中，Apache Jakarta 已经证明可以维护他们的库，最近 Sun 在为 Glassfish v3 生成高质量实现方面做了很多工作。无论如何，我们也有所有模块的来源，所以如果其他都失败了，我们可以自己维护它们。
Sun 规范通常非常严格，这意味着符合规范的实现可以轻松互换。看看 servlet 容器。
在这种特殊情况下，我建议看一下 JavaServer Faces，因为它是 Java EE 6 的一部分，这意味着它可以使用并维护很长时间。然后我们选择使用 MyFaces Tomahawk 进行扩充，因为它提供了一些有用的附加功能，而且它是一个 jakarta 项目。
JBoss Seam 或其他没有任何问题。只是他们不太关注对我们如此重要的维护问题。
于 2010-03-30T11:25:02.540 回答
6
如果您已经拥有 Spring，我可以看到使用 Spring，但是对于新项目，有什么意义呢？我会直接使用 Java EE 6（ejb3、jsf2.0 等）
如果客户对 Flex 满意，那就去吧。使用 BlazeDS 或类似的 - 没有 mvc。您可能会在该部分（在服务器和客户端之间交换数据）上花费更多时间，但您可以完全控制双方。
不要使用 Vaadin，除非你想杀死你的浏览器。此外，一旦您的页面变得更加复杂，您就会花费更多时间来处理代码。此外，您的思维方式需要完全改变，您对标准前端开发的任何了解都将是浪费。您不必使用 HTML 或 JS 的论点没有多大意义。即使你不使用它，你仍然必须知道它。它最终呈现为 HTML 和 JS。然后尝试调试它——确保你有几天的时间来做简单的事情。另外，我无法想象不了解 html/js 的 Web 开发人员。
我只是不明白为什么人们要尝试所有这些抽象而不是直接使用 Java EE。
于 2011-09-03T13:57:28.593 回答
5
为什么在 2010 年仍然有关于 EJB 成为重量级的传言？似乎人们没有更新 Java EE 技术。试一试，您会惊喜地发现 Java EE 6 中的事情是如何简化的。
于 2010-04-24T12:02:44.890 回答
4
您的问题的答案取决于您的项目要求。如果您不需要消息队列、容器管理的全局事务等 Java EE 功能，请使用 tomcat+spring。
同样根据经验，我发现需要大量 Web 服务集成、调度、消息队列的项目最好使用一些 Java EE 堆栈来完成。好处是使用 spring，您仍然可以与在应用程序服务器中运行的 Java EE 模块集成。
Java EE 6 与以前的版本有很大不同，它确实使一切变得容易得多。Java EE 6 结合了来自不同 Java 社区的最佳想法 - 例如，来自 Spring 框架的 Rod Johnson 积极参与了 Java EE 6 中依赖注入 JSR 的制作。使用 Java EE 6 的一个好处是您可以根据一个标准，在某些组织中对于供应商支持等可能很重要。
GlassFish v3 支持 Java EE 6，它非常轻量级并且启动速度非常快。我一直在使用 glassfish v3 进行开发，而且它真的很容易配置。它带有一个非常用户友好的管理控制台，可让您以图形方式管理您的服务器。
如果您使用的是 GlassfishV3 和 JSF 2，那么您可以利用 Java EE 6 的 CDI 特性，这让您可以轻松地在 JSF 中创建对话（例如，类似向导的页面）。
话虽如此，使用 Java EE 6 还需要您学习新的 API。根据可用的时间范围，它可能不是您的最佳选择。Tomcat 已经存在很长时间了，并且 tomcat+spring 组合已被许多 Web 项目采用，这意味着周围有很多文档/论坛。
于 2010-03-25T04:19:52.527 回答
3
如果您需要 Java EE 全栈，我建议您使用 GlassFish 3.1。与实现部分或全部 Java EE 6（JBoss 6、WebLogic 10.3.4）的其他 Java EE 容器相比，它启动得非常快，重新部署只需几秒钟，几乎所有都可以通过约定而不是配置来完成，非常友好。
我想要一些“轻量级”的东西，您可以自定义具有所需功能的 Apache Tomcat 7.x。我经常使用以下库： Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - only resource local transactions JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime
过去 10 年一直是 Java EE 开发人员（我遭受了早期的 EJB、JSF 和 Web 技术的困扰），Java EE 6 非常简单，耦合性很好，并且当前的硬件运行流畅，因此激发 Spring 的最初原因不再有效。
于 2011-05-24T01:28:53.320 回答
3
我曾在 Spring 和 Java EE 6 中工作过。根据我的经验，我可以说，如果您要使用古老的 JSP 或专有 Flex，那么如果您继续使用 Spring，那么您是安全的。
但是，如果您要继续使用 JSF，那么是时候转向 Java EE 6。使用 Java EE 6，您正在转向 Facelets 以及标准化的脚本库和组件库。不再有脚本不兼容和组件库矩阵。
关于 Spring MVC，只要你的项目不会变得太大就可以了。如果它是一个巨大的企业应用程序，请坚持使用 Java EE 6。因为这是您可以有序地维护自己的组件库和资源包的唯一方法。
于 2010-06-30T05:27:46.990 回答
1
我还是更喜欢春天。
我会传递 JSF。我认为这是一项死技术。Spring MVC 将是一个更好的选择。Flex也是如此。从契约优先 XML 服务的角度考虑，您可以将后端与 UI 完全分离。
于 2010-03-23T12:09:17.307 回答
0
没有阅读所有内容，只是告诉您现在可以在 Java EE 6 的战争中使用 EJB3，因此您可以在 Tomcat 上使用 EJB3（我认为）。
于 2010-04-05T19:20:43.790 回答
0
我推荐 Spring + Tomcat，除非您可以等待 glassfish v3 和 Weld 变得更加成熟。当前，在使用启用了 CDI 的应用程序运行 glassfish 时，内存消耗/cpu 负载存在一些问题。
于 2010-03-30T02:09:40.577 回答
-3
我向你推荐了 Tomcat with Spring，因为：
- Spring 可以为 JSP 创建 backing beans
- 您将使用 Spring 通过 JPA 持久化对象
选择Tomcat是不错的选择，因为不需要任何重量级的处理
于 2010-03-30T10:03:30.033 回答