20

私は新しいプロジェクトを開始することを計画しており、現在最先端の Java Web フレームワークを検討しています。Guice を中心にアプリケーションを構築することにしました。Squill/JEQUEL/JaQu などの非常に軽量な ORM を使用する可能性がありますが、Web フレームワークを決定できません。このような軽量環境に最も適しているのはどれですか? また、Guice との統合に最も適しているのはどれですか?

4

6 に答える 6

22

11月に新しいプロジェクトのプログラムを開始したので、このトピックに関するいくつかの経験を集めました。プロジェクトは現在後期段階にあります。

私にとって、次の設計ガイドラインが重要でした。

  • 使用するのが楽しく、将来的に一般的に使用される最新のテクノロジースタックを使用してください。
  • プロジェクトアーティファクトの数を減らします-意味のある場合はアノテーション/Javaコードを使用し、XMLを省略します。
  • オープンソースのフレームワークを使用する
  • 活発なコミュニティを持つ
  • アルファステージではありません
  • 軽量です
  • 概念の重複を避ける
  • その中の概念を、優れたプログラマーであるにもかかわらず、依存性注入（DI）やWebフレームワークを使用したことがない2人の開発者に説明できます。
  • 将来のプロジェクトの技術的基盤として役立つことができます

DIコンテナとしてのGoogleGuiceは当然の選択でした。明らかに、優秀な開発者と優れたコミュニティを備えた、最もよく考えられたDIコンティナーです。上記のすべての箇条書きを満たしています。

そこで、基本的な技術スタックを設定しました。Guiceから始めて、永続性のためにHibernateを追加しました（ warp-persistおよびwarp-servletとともに）。次に、何かを選択する基本的なDAOを作成しました。

次に、次のことを試みました。その上に別のWebフレームワークを追加しました。

DAO、ヘッダー、および4つのフレームワークすべてを含むテキストフィールドが入力されたテーブルを含む単純なページを作成しました。

これらは、4つのフレームワークを比較したときの私の発見でした。

XSLTとXStreamは、一種の筋金入りのアプローチです。これは実際にはフレームワークではありませんが、高性能アプリケーションのための実行可能な完全にステートレスなテクノロジーです。これは、テストページを提供する最も速い方法でした。デバッグモードでは、ローカルホストで3ミリ秒であるのに対し、他のフレームワークでは約30〜50ミリ秒です。

Guiceの統合は比較的スムーズで、warp-servletを使用して良好でした。これにより、サーブレットに挿入し、httprequest、httpresponse、sessionを他のオブジェクトに渡すことなく挿入できました。短所：このスタックを検討するのは私だけなので、コミュニティはまったくありません。-すぐに使用できるコンポーネントはありません。

次に、JSFとGuiceを調べました。もちろん、インジェクターをサーブレットコンテキストに配置し、サービスロケーターとしてguiceを使用することは可能です。単純なアプローチでは、バッキングBeanを別の場所に注入することは不可能です。カスタム変数リゾルバーを使用すると、これは部分的に解決されますが、JSFファイル内のすべてのIDE統合が失われ、バッキングBeanに醜いFQNを使用するか、どこかに文字列->Guiceキーマッピングを作成する必要があります。どちらも醜いです：

ワープウィジェット：これを使って簡単な例を作成しました。それは初期のアルファ段階です。使い方は素晴らしく、そのコンポーネントは自分で簡単に実装して再利用できます。これは、完全なGuice統合を備えたタイプセーフなHTMLを提供することを目的としています。当時はアクティブな開発者が1人しかいなかったようで、現在はGuice 2.0に適切に取り組んでいるため、コミュニティはほとんど存在していません。それは魅力のように機能し、適度に高速でしたが、私はアルファテスターでした。それは私が商業プロジェクトのためにそれを考えるにはあまりにも危険でした。

Apache Wicket：このプロジェクトは、最初にwicket-iocとwicket-guiceがコアダウンロードに含まれていることに驚きました。Webページへのコンストラクタインジェクションはできません。setter+fieldのみです。Wicket Webページへの挿入は簡単で、入力するフィールドに追加するだけですが、バックグラウンドでどのように機能@Injectするかを理解する必要はありません。トリッキーなことが起こっています。Webページの挿入は理論的には可能ですが、マウントされたURLを使用できなくなるため、一度も使用したことはありません。さらに、永続化/シリアル化された状態で混乱します。挿入されたクラスのメンバーは、ブラウザバックサポートを有効にするために必要なWebページのシリアル化で透過的に処理されます。Wicketは外部アーティファクトを使用しません-URLのほんの少しの構成アプリケーションクラスで。したがって、すべての構成はJavaで行われ、Guiceモデルによく適合します。HTMLとJavaの明確な分離。多数の高品質なコンポーネントの大部分と同じように、オープンソースです。それは2005年（？）以来であり、トップレベルのApacheプロジェクトです。機能豊富なフレームワークですが、そのAPIはかなりコンパクトです（すべてのコアクラスが画面上の単一のJPEGに収まります）。他とは異なり、独自のIoCメカニズムを備えていませんが、IoCをSpring FrameworkやGuiceなどで提供できるサービスと見なしており、その哲学によりGuiceの統合に優れています。本当にスマートで簡単なAjaxサポートについて言及しましたか？

深く評価されていないフレームワーク：tapestry5-独自のIoCをもたらします。 Seam：それ自体はフレームワークではありませんが、通常はSpring、JSFを組み合わせたメタフレームワークです。Hibernate。（ただし、Springは理論的にはGuiceに置き換えられる可能性があります。）

概要：評価されたフレームワークの中で、ApacheWicketが明らかに勝者でした-Guice統合+言及された他のすべての基準に関して。

私たち2人のほかに、他の何人かの人々は以前にこの問題を抱えていました。

于 2009-02-08T02:24:20.877 に答える
7

Wicket には Guice モジュールが組み込まれていますが、私は使用していません (ただし、Wicketはかなり使用しており、気に入っています)。

于 2009-01-27T15:07:11.973 に答える
3

Guice と Stripesの統合に関する記事はこちら

于 2009-02-12T19:43:01.037 に答える
3

Play フレームワークは素晴らしいものです。Guice をサポートしています (まだ試していません)。

于 2011-03-25T19:50:06.087 に答える
1

優れた軽量 Web コンテナーはSimpleです。非常にパフォーマンスが高く、 RestletやJerseyなどのフレームワークで使用できます。

于 2009-01-26T22:59:11.630 に答える