哪个Java Web Framework最适合Google Guice？

我打算开始一个新项目,并且正在研究当前最先进的Java Web框架.我决定围绕Guice构建我的应用程序,并且可能使用像Squill/JEQUEL/JaQu或类似的非常轻量级的ORM,但我无法决定Web框架.哪一个最适合这种轻量级环境？哪一个最好与Guice整合？

我在11月开始为一个新项目开始编程时,已经收集了一些关于这个主题的经验.该项目现在处于后期阶段.

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

使用现代技术堆栈既有趣又可以在将来使用.

减少项目工件的数量 - 在有意义的地方使用注释/ Java代码,省略XML.

使用开源的框架

拥有一个活跃的社区

不是阿尔法阶段

很轻巧

避免重复概念

我可以向我的两位开发人员解释其中的概念,尽管他们是优秀的程序员,却从未使用过依赖注入(DI)或Web框架.

可以作为未来项目的技术基础

Google Guice作为DI容器是一个显而易见的选择 - 显然是最精心设计的DI contianer,拥有出色的开发人员和良好的社区.它符合上面提到的所有要点.

所以我建立了我的基本技术堆栈.从Guice开始,添加了Hibernate for persistence(以及warp-persist和warp-servlet).然后我写了一些基本的DAO来选择一些东西.

然后我尝试执行以下操作:在其上添加了一个不同的Web框架.

XSLT与xStream使用常规HTTP servlet

JSF- MyFaces

Apache Wicket

经小部件

我创建了一个带有表的简单页面,由DAO填充,标题和包含所有四个框架的文本字段.

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

XSLT和XStream是一种硬核方法.它不是一个真正的框架,而是一个可行的完全无状态的高性能应用技术.这是迄今为止服务测试页面的最快方式.在调试模式下,localhost为3 ms,而其他framworks为30-50 ms.

使用warp-servlet进行Guice集成相对平稳和良好,这使我能够注入servlet并在其他对象中注入httprequest,httpresponse,session,而不会传递它们.缺点:根本没有社区,因为我是唯一会考虑这个堆栈的人. - 没有现成的组件.

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

优点:良好的社区,许多开发人员在就业市场(没有我的标准).如果出现问题,你不会因为选择JSF而被解雇.

缺点:带来自己的控制反转控制(IoC)机制,它在概念上与guice冲突.

warp-widgets:我创建了一个简单的例子来使用它来获得乐趣; 这是早期的alpha阶段.它很好用,它的组件易于实现和重用.它旨在为类型安全的HTML提供完美的Guice集成.既然它当时只有一个活跃的开发人员,现在谁正在为Guice 2.0工作,我会说社区几乎不存在.它的工作就像一个魅力,速度相当快,但我会成为alpha测试员.对我来说,这对于商业项目来说太冒险了.

Apache Wicket: this project first suprised me with wicket-ioc and wicket-guice coming together in the core download. Constructor injection in web pages is not possible, only setter+field. Injection in Wicket web pages is easy, just add @Inject to the fields you want to fill - but you're not supposed to understand how it works in background. Tricky stuff happening. Injection of web pages is theoretically possible - but I have not used it once, since this makes it impossible to use mounted URLs, plus it will mess with the persisted/serialized state. Injected members of classes are dealt transparently with web page serialisation, which is necessary for enabling browser-back support. Wicket uses zero external artifacts - just a little configuration of the URLs in a application class. So all configuration is done in Java - which fits the Guice model well. Clear seperation of HTML and Java. It's open-source just like the majority of the components that are numerous and of good quality. It's around since 2005(?) and is a top-level Apache project. Although it's a feature-rich framework, its API is reasonable compact (all core classes fit in a single JPEG on my screen). Unlike others, it does not bring a IoC mechanism of its own, but rather thinks of IoC as a service that can be provided by Spring Framework, Guice, etc. and that philosophy makes it superior w.r.t. Guice integration. Did I mention really smart and easy Ajax support?

框架没有深入评估:tapestry5 - 带来自己的IoC. Seam:不是一个独立的框架,而是一个通常与Spring,JSF合作的元框架.休眠.(虽然Spring理论上可以被Guice取代.)

总结:在评估的framworks中,Apache Wicket是明显的赢家 - 关于Guice集成+提到的所有其他标准.

除了我们两个,其他一些人以前遇到过这个问题.

Wicket内置了一个Guice模块,我没有使用过(但我已经使用了Wicket,并且喜欢它).