哪个Java Web框架最适合Google Guice?[闭门]

对我来说,以下设计指南很重要:

• 使用一个既有趣又能在将来广泛使用的现代技术堆栈。
• 减少项目工件的数量-在有意义的地方使用注释/Java代码,省略XML。
• 拥有一个活跃的社区
• 我们不是阿尔法阶段
• 它们很轻
• 避免概念重复
• 我可以向我的两位开发伙伴解释其中的概念,尽管他们是优秀的程序员,但从未使用过 dependency injection
• 可作为未来项目的技术基础

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是一种核心方法。它不是一个真正的框架,而是一种适用于高性能应用程序的完全无状态的可行技术。这是目前为止为测试页面提供服务的最快方式。在调试模式下,本地主机的运行时间为3毫秒,而其他framworks的运行时间为30-50毫秒。

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

• 优点:良好的社区,就业市场上有很多开发商(对我来说没有标准)。如果出现问题,你不会因为选择JSF而被解雇。
• 缺点:自带 Inversion of control (IoC)在概念上与guice冲突的机制。

warp小部件:为了好玩,我创建了我的简单示例;这是早期阿尔法阶段。它很好用,它的组件也很容易实现和重用。它的目标是提供类型安全的HTML和完美的GUI集成。因为那时它看起来只有一个活跃的开发人员,而他现在可能正在开发Guice 2.0,所以我认为这个社区几乎不存在。它就像一个符咒,相当快,但我会是阿尔法测试仪。这太冒险了,我不能把它当作一个商业项目来考虑。

ApacheWicket:这个项目首先让我大吃一惊,Wicket ioc和Wicket guice一起出现在核心下载中。无法在网页中注入构造函数,只能在setter+字段中进行。Wicket网页中的注入很容易,只需添加 @Inject how it works in background . 棘手的事情正在发生。从理论上讲,web页面的注入是可能的——但我没有使用过它一次,因为这使得无法使用挂载的URL,而且它会扰乱持久化/序列化状态。 类的注入成员以透明的方式处理网页序列化,这对于启用浏览器后台支持是必要的。Wicket使用零外部工件-只是对 URLs API 结构合理紧凑(所有核心类均适合于单个 JPEG 在我的屏幕上)。与其他机构不同的是,它没有建立自己的国际奥委会机制,而是将国际奥委会视为一项可以由国际奥委会提供的服务 Spring Framework ,Guice等,而这一理念使其优于w.r.t.Guice集成。 我提到过真正的智能和简单的Ajax支持吗?

未深入评估的框架:tapestry5——带来了自己的IoC。 Seam

总结:评估框架的, 阿帕奇·维克特显然是赢家 -关于Guice集成+提及的所有其他标准。

have had this problem before .

Wicket has a Guice module built in ,我没有用过(但我用过 Wicket

integrating Guice with Stripes

The Play framework 这是一个不错的。 It has Guice support (而且我还没有试过)。

Simple . 它的性能非常好,可以与诸如 Restlet 和 Jersey .

Mojave MVC Web Framework 是一个非常简单、轻量级的框架,它集成了Guice。