哪些Java Web框架最适合Google Guice？ [英] Which Java Web Framework fits best with Google Guice?

问题描述

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

解决方案

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

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

• 使用现代技术堆栈，使用起来很有趣，将来会一般使用。


• 减少项目工件的数量 - 使用注释/ Java代码


• 使用开放源码的框架


• 拥有一个活跃的社区


• 不是alpha阶段


• 轻量级


• 避免重复概念


• 我可以解释概念对我的两个开发人员来说，尽管是好的程序员，但从未使用依赖注入（ DI / web框架。


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

< a href =http://en.wikipedia.org/wiki/Google_Guice =nofollow noreferrer> Google Guice 作为DI容器是一个明显的选择 - 显然是最有思想的DI contianer，拥有辉煌的开发人员和良好的社区。它符合上述所有的要点。

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

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

• XSLT ， xStream 使用常规HTTP servlet


• JSF- MyFaces


• Apache Wicket


• warp-widgets

我创建了一个带有表的简单页面，由DAO填充，标题和一个带有所有四个框架的文本框。

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

XSLT和XStream是ki nd的核心方法。它不是一个真正的框架，而是一个可行的完全无状态的高性能应用程序技术。这是迄今为止测试页面最快的方式。在调试模式下，localhost上的3 ms和其他framworks的大约30-50 ms。

使用warp-servlet，Guice集成相对平稳，很好，这使我能够注入servlet，并在其他对象中注入httprequest，httpresponse，session，而不会传递给它们。缺点：根本没有社区，因为我是唯一可以考虑这个堆栈的人。 - 没有即用型组件。

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

• 优点：良好的社区，许多开发人员在就业市场（对我来说没有标准）。如果出现问题，你不会被解雇选择JSF。


• 缺点：带来自己的反转控制（IoC）机制，在概念上与guice冲突。

warp-widgets：我创建了我使用这个乐趣的简单的例子;它是早期的alpha阶段。这是很好的使用，它的组件很容易实现和自己重用。它旨在提供具有完美的Guice集成的类型安全的HTML。既然看起来它只有一个活跃的开发人员，那么现在谁现在可以在Guice 2.0上工作，我会说社区几乎不存在。它的工作就像一个魅力，是相当快的，但我会是alpha测试者。对于一个商业项目来说，我觉得这太冒险了。

Apache Wicket：这个项目首先在wicket-ioc和wicket-guice在核心下载中聚集在一起。 Web页面中的构造器注入是不可能的，只有setter +字段。在Wicket网页中注入很简单，只需将 @Inject 添加到您要填写的字段，但您不应该理解它在背景中的工作原理。发疯的东西。网页注入在理论上是可能的 - 但是我没有使用过一次，因为这样就不可能使用挂载的URL，加上它会使持久化/序列化状态混乱。
注入类的成员透明地处理网页序列化，这对于启用浏览器返回支持是必需的。 Wicket使用零个外部工件 - 只需稍微配置一个应用程序类中的 URL 。所以所有的配置都是用Java完成的 - 它适合Guice模型。清楚分离HTML和Java。它是开源的，就像大多数众多且质量好的组件一样。自2005年以来（？），是一个顶级的Apache项目。虽然它是一个功能丰富的框架，但其 API 是合理的（所有核心类都适合单击 JPEG 在我的屏幕上）。与其他人不同，它不会带来自己的IoC机制，而是认为IoC可以由 Spring框架，Guice等，这种哲学使其成为优势Guice整合。
我提到真正聪明和容易的Ajax支持？

框架没有深入评估：tapestry5 - 带来自己的IoC。
Seam ：不是一个框架，而是一个通常是一个框架comines Spring，JSF。休眠。 （虽然Spring理论上可以被Guice取代。）

总结：评估的框架， Apache Wicket是明确的赢家 - 相对于Guice integration +提到的所有其他标准。

除了我们两个，另外一些人之前有这个问题。

I'm planning to start on a new project and am looking at the current state-of-the-art Java web frameworks. I decided to build my application around Guice, and am likely to use a very lightweight ORM like Squill/JEQUEL/JaQu or similar, but I can't decide on the web framework. Which one would fit best in such a lightweight environment? And which one integrates best with Guice?

解决方案

I have gathered some experience on this topic, as I started to program on a new project in November. The project is in a late stage now.

For me, the following design guidelines were important:

• Use a modern technology stack that is both fun to use and will be in general use in future.
• Reduce the number of project artifacts - use annotations/Java code where it makes sense, omit XML.
• Use frameworks that are open-source
• Have an active community
• Are not alpha stage
• Are lightweight
• Avoid duplication of concepts
• I can explain the concepts in it to my two fellow developers, who - despite being good programmers - have never used dependency injection (DI) or web frameworks.
• Can serve as a techological basis for future projects

Google Guice as a DI container was an obvious choice - clearly the most well-thought DI contianer, with brilliant developers and a good community. It fulfills all the bullet points mentioned above.

So I set up my basic techology stack. Started with Guice, added Hibernate for persistence (along with warp-persist and warp-servlet). Then I wrote some basic DAO that selects something.

Then I tried to do the following: added a different web framework on top of that.

• XSLT with xStream using regular HTTP servlets
• JSF- MyFaces
• Apache Wicket
• warp-widgets

I created a simple page with a table, populated by the DAO, headers and a textfield with all four frameworks.

These were my findings when comparing the four frameworks.

XSLT and XStream is kind of a hardcore-approach. It's not really a framework, but a viable completely stateless techology for high-performance applications. This was by far the fastest way of serving the test page. In debug mode, 3 ms on localhost versus about 30-50 ms with the other framworks.

Guice integration was relatively smooth and good using warp-servlet which enabled me to inject into servlets and injects httprequest, httpresponse, session in other objects, without passing them around. Disadvantages: no community at all, since I am the only person who would consider this stack. - no ready-to-use components.

Then I took a look at JSF and Guice: it is of course possible to put the injector in the servlet context and use guice as a service locator. With the straightforward approach it's impossible to inject backing beans somewhere else. Using a custom variable resolver solves this partially, but then you lose all IDE integration in your JSF files plus you will have to use ugly FQN for your backing beans, or build a string->Guice key mapping somewhere. Both are ugly as:

• Advantages: good community, many developers in the job market (no criteria for me). You won't get fired for chosing JSF if something goes wrong.
• Disadvantages: brings its own Inversion of control (IoC) mechanism which clashes conceptually with guice.

warp-widgets: I created my simple example using this for fun; it's early alpha stage. It was nice to use and its components are easy to implement and reuse by myself. It aims to provide typesafe HTML with perfect Guice integration. Since it looked like it had only one active developer back then, who is now propably working on Guice 2.0, I would say the community is nearly non-existent. It worked like a charm, was reasonably fast, but I would have been alpha tester. That was simply too risky for me to consider it for a commercial project.

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?

Frameworks not deeply evaluated: tapestry5 - brings its own IoC. Seam: not a framework on its own, but a meta-framwwork which normally comines Spring, JSF. Hibernate. (Though Spring may theoretically be replaced by Guice.)

Summary: of the evaluated framworks, Apache Wicket was the clear winner - with respect to Guice integration + all other criteria mentioned.

Besides us two, some other people have had this problem before.

这篇关于哪些Java Web框架最适合Google Guice？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！