哪个 Java Web 框架最适合 Google Guice？ [关闭]

Posted 2023-04-12

【中文标题】哪个 Java Web 框架最适合 Google Guice？ [关闭]

【英文标题】：Which Java Web Framework fits best with Google Guice? [closed]

【发布时间】：2009-01-26 22:49:32

【问题描述】：

我计划开始一个新项目，并正在研究当前最先进的 Java Web 框架。我决定围绕 Guice 构建我的应用程序，并且可能会使用非常轻量级的 ORM，例如 Squill/JEQUEL/JaQu 或类似的，但我无法决定使用 Web 框架。哪一个最适合这样一个轻量级的环境？哪一个与 Guice 集成得最好？

【参考方案1】：

当我在 11 月开始编写一个新项目时，我已经收集了一些关于这个主题的经验。该项目目前处于后期阶段。

对我来说，以下设计指南很重要：

使用既有趣又会在未来普遍使用的现代技术堆栈。 减少项目工件的数量 - 在有意义的地方使用注释/Java 代码，省略 XML。 使用开源框架 拥有活跃的社区 不是 alpha 阶段 轻巧 避免概念重复 我可以向我的两位开发人员解释其中的概念，尽管他们是优秀的程序员，但他们从未使用过 dependency injection (DI) 或 Web 框架。 可以作为未来项目的技术基础

Google Guice 作为 DI 容器是一个显而易见的选择 - 显然是最深思熟虑的 DI 容器，拥有出色的开发人员和良好的社区。它满足上述所有要点。

所以我设置了我的基本技术堆栈。从 Guice 开始，添加 Hibernate 用于持久性（以及 warp-persist 和 warp-servlet）。然后我写了一些基本的DAO 来选择一些东西。

然后我尝试执行以下操作：在此基础上添加了一个不同的 Web 框架。

XSLT 和 xStream 使用常规 HTTP servlet JSF- MyFaces Apache Wicket warp-widgets

我创建了一个简单的页面，其中包含一个表格，由 DAO、标题和一个包含所有四个框架的文本字段填充。

这些是我比较四个框架时的发现。

XSLT 和 XStream 是一种硬核方法。它不是一个真正的框架，而是一种适用于高性能应用程序的可行的完全无状态的技术。这是迄今为止提供测试页面的最快方式。在调试模式下，localhost 为 3 毫秒，而其他框架为 30-50 毫秒。

使用 warp-servlet 的 Guice 集成相对顺利和良好，这使我能够注入 servlet 并在其他对象中注入 httprequest、httpresponse、session，而无需传递它们。缺点：根本没有社区，因为我是唯一会考虑这个堆栈的人。 - 没有现成的组件。

然后我看了一下 JSF 和 Guice：当然可以将注入器放在 servlet 上下文中，并使用 guice 作为服务定位器。使用简单的方法，不可能在其他地方注入支持 bean。使用自定义变量解析器可以部分解决这个问题，但是您会丢失 JSF 文件中的所有 IDE 集成，而且您将不得不使用丑陋的 FQN 作为支持 bean，或者在某处构建字符串->Guice 键映射。两者都很丑：

优点：良好的社区，就业市场上有许多开发人员（对我没有标准）。如果出现问题，您不会因为选择 JSF 而被解雇。 缺点：自带Inversion of control (IoC) 机制，在概念上与 guice 冲突。

warp-widgets：为了好玩，我创建了一个简单的示例；这是早期的阿尔法阶段。它很好用，它的组件很容易实现和我自己重用。它旨在提供具有完美 Guice 集成的类型安全 html。由于当时它看起来只有一个活跃的开发人员，现在可能正在开发 Guice 2.0，我想说这个社区几乎不存在。它就像一个魅力，相当快，但我会成为 alpha 测试员。这对我来说风险太大，无法考虑将其用于商业项目。

Apache Wicket：这个项目首先让我吃惊的是 wicket-ioc 和 wicket-guice 在核心下载中结合在一起。网页中的构造函数注入是不可能的，只有setter+field。在 Wicket 网页中注入很容易，只需将 @Inject 添加到您要填写的字段中 - 但您不应该理解 how it works in background。棘手的事情正在发生。理论上可以注入网页 - 但我没有使用过一次，因为这使得无法使用挂载的 URL，而且它会混淆持久化/序列化状态。 类的注入成员被透明地处理为网页序列化，这是启用浏览器支持所必需的。 Wicket 使用零外部工件 - 只需在应用程序类中对 URLs 进行一点配置。所以所有的配置都是用 Java 完成的——这很适合 Guice 模型。 HTML 和 Java 的清晰分离。它是开源的，就像大多数数量众多且质量良好的组件一样。它自 2005 年（？）以来就已经存在，并且是一个*** Apache 项目。虽然它是一个功能丰富的框架，但它的API 相当紧凑（所有核心类都适合我屏幕上的单个JPEG）。与其他人不同的是，它并没有带来自己的 IoC 机制，而是将 IoC 视为可以由Spring Framework、Guice 等提供的服务，并且这种理念使其优于 w.r.t。 Guice 集成。 我是否提到过非常智能且简单的 Ajax 支持？

未深入评估的框架：tapestry5 - 自带 IoC。 Seam：本身不是一个框架，而是一个元框架，通常来自 Spring、JSF。休眠。 （虽然理论上 Spring 可能会被 Guice 取代。）

总结：在评估的框架中，Apache Wicket 是明显的赢家 - 关于 Guice 集成 + 提到的所有其他标准。

除了我们两个，还有一些人have had this problem before。

【讨论】：

喜欢的清单，但我认为 warp-*** 没有意义。

请注意，这个答案来自 2009 年。这显然不再是最新的

【参考方案2】：

Wicket has a Guice module built in，我没用过（但我用过不少Wicket，很喜欢）。

【讨论】：

wicket 的问题在于它是一个非托管框架，即您负责实例化组件。我们在后台处理这个问题的方式是在组件实例化侦听器上请求注入。它可以工作 - 但绝对不是 用于 guice 的 Web 框架。

【参考方案3】：

这是一篇关于integrating Guice with Stripes的文章

【参考方案4】：

The Play framework 是一个不错的选择。 It has Guice support（我也没试过）。

【参考方案5】：

一个好的轻量级网络容器是Simple。它的性能非常好，可以与Restlet 和Jersey 等框架一起使用。

【讨论】：

Guice + DI 框架 == PITA。 Jersey 与依赖注入竞争/干扰，两者的开发人员从未制定出合理的解决方案。有桥梁、kludges 和 hacks，但泽西岛在 DI 中表现不佳。

相反，Jersey 有自己的 DI 抽象，因此插入 DI 提供程序很容易。 Jersey + Guice 非常适合我们。

【参考方案6】：

Mojave MVC Web Framework 是一个包含 Guice 的非常简单、轻量级的框架。