我在11月开始为一个新项目进行编程时，已经在该主题上积累了一些经验。该项目现在处于后期。
对我而言，以下设计准则很重要：
- 使用既有趣又会在将来广泛使用的现代技术堆栈。
- 减少项目工件的数量-在有意义的地方使用注释/ Java代码，省略XML。
- 使用开源框架
- 拥有活跃的社区
- 不是Alpha阶段
- 轻巧
- 避免概念重复
- 我可以向我的两个开发人员解释其中的概念，尽管他们是优秀的程序员，但他们从未使用过依赖注入（DI）或Web框架。
- 可以作为未来项目的技术基础
将Google Guice作为DI容器是一个显而易见的选择-
显然是最有思想的DI容器，拥有出色的开发人员和良好的社区。它满足了上述所有要点。
因此，我建立了基本的技术堆栈。从Guice开始，添加了Hibernate以实现持久性（以及warp-
persist和warp-
servlet）。然后，我写了一些基本的DAO来进行选择。
然后，我尝试执行以下操作：在此之上添加一个不同的Web框架。
- 使用常规HTTP Servlet的XSLT与xStream
- JSF- MyFaces
- Apache Wicket
- 经线小部件
我创建了一个带有表的简单页面，该表由DAO，页眉和带有四个框架的文本字段组成。
比较四个框架时，这些就是我的发现。
XSLT和XStream是一种硬性方法。它并不是真正的框架，而是适用于高性能应用程序的可行的完全无状态的技术。这是迄今为止提供测试页最快的方法。在调试模式下，本地主机上为3毫秒，而其他framworks则为30-50毫秒。
Guice集成使用warp-
servlet相对平稳且良好，这使我能够注入servlet并在其他对象中注入httprequest，httpresponse，会话，而无需传递它们。缺点：根本没有社区，因为我是唯一考虑此堆栈的人。-没有现成的组件。
然后，我看了一下JSF和Guice：当然可以将注入器放在servlet上下文中，并将guice用作服务定位器。使用简单的方法，不可能将支持bean注入其他地方。使用自定义变量解析器可以部分解决此问题，但随后您将失去JSF文件中的所有IDE集成，此外，您将不得不使用难看的FQN作为后备bean，或者在某个地方构建string->
Guice键映射。两者都是丑陋的：
- 优势：良好的社区，就业市场上有许多开发人员（对我而言没有标准）。如果出现问题，您不会因选择JSF而被解雇。
- 缺点：带来了自己的控制反转（IoC）机制，在概念上与guice冲突。
warp-widgets：我创建了一个简单的示例，以此为乐；这是早期的Alpha阶段。很好用，它的组件很容易自己实现和重用。它旨在为Typesafe
HTML提供完美的Guice集成。由于当时看起来只有一个活跃的开发人员，而他现在正在致力于Guice
2.0的开发，所以我想说社区几乎不存在。它像一个魅力一样运作，相当快，但我本来应该是alpha测试员。对于我来说，考虑将其用于商业项目实在太冒险了。
Apache Wicket：该项目首先使我感到惊讶，在核心下载中汇集了wicket-ioc和wicket-
guice。无法在网页中进行构造函数注入，只能使用setter +
field。在Wicket网页中进行注入很容易，只需将其添加
@Inject到要填充的字段中即可-
但您不应该了解它在后台的工作方式。棘手的事情发生了。从理论上讲，可以注入网页-
但是我没有使用过一次，因为这使得无法使用已安装的URL，而且它还会干扰持久化/序列化状态。注入的类成员将通过网页序列化透明地处理，这对于启用浏览器后备支持是必需的。Wicket使用零外部工件-
只需配置一些URL在应用程序类中。因此，所有配置都在Java中完成-
非常适合Guice模型。清除HTML和Java的分隔。就像大多数组件一样，它是开源的，数量众多且质量很高。它自2005年以来一直是一个顶级Apache项目。尽管它是一个功能丰富的框架，但它的API相当紧凑（所有核心类都适合屏幕上的单个JPEG）。与其他系统不同，它没有带来自己的IoC机制，而是将IoC视为可由Spring
framework，Guice等提供的服务，并且这种哲学使其与Guice集成更为出色。我是否提到了真正聪明又容易的Ajax支持？
未深入评估的框架：tapestry5-带来自己的IoC。
Seam：不是一个单独的框架，而是通常在JSF的Spring中包含的元框架。冬眠
（尽管理论上可以用Guice代替Spring。）
简介：在评估过的framworks中， Apache Gucket无疑是赢家 -就Guice集成+提及的所有其他条件而言。
除了我们两个，其他人以前也有这个问题。
