25

私はJavaWeb開発にまったく慣れていないので、学習するのに適したJavaWebフレームワークを選択したいと思います。ApacheWicketフレームワークとPlayframeworkに関していくつかの本当に良いエコーを見つけました。私はそれらの1つに行くことにしました。しかし、私は選択する必要があります;-)

では、何を選択するのか、そしてその理由は何ですか？

編集

私の要件：

  • 私はDjangoで開発するのに良い経験をしたので、同様のフレームワークは素晴らしいでしょう、
  • Javaが実際に提供するものを利用できるように、他の主流のJava機能（ライブラリ、ツールなど）と対話できるフレームワークが必要です。
4

4 に答える 4

51

WicketとPlayは、2つの非常に異なるタイプのフレームワークです。

PlayはMVCフレームワークであり、おそらくDjangoからのアクセスに慣れていると思います。Djangoと同様に、Webビット以上のものを提供し、JPAベースのORMフレームワーク、スキャフォールディングツール、およびおそらくもっと多くのものを提供します（私は実際の経験がありません）。彼らは彼らのサイトに素晴らしいチュートリアルを持っています、そしてあなたはおそらくそこにDjangoの類似点を見るでしょう。

Wicketはコンポーネント指向のフレームワーク（JSFやTapestryなど）であり、オブジェクト指向の設計に重点を置いています。それ自体もMVCですが、ページは通常、自己完結型で再利用可能なコンポーネント（ViewとController、プラグ可能なモデル）を構成することによって構築されます。これらのコンポーネントは、標準の継承と構成によって拡張でき、マークアップはコードから非常に明確に分離されており、簡単に変更できます。

Wicketはイベントのコールバックと状態を自動的に管理できるため、ページがどれほど複雑であっても、URLをまったく考える必要はありません。クリックすると消えるクリック可能なボタンの簡単な例（非常に便利）：

  // In a page constructor
  add(new Link("link") {
        public void onClick() {
          setVisible(false);
        }
    });

サーバー側の状態を使用する必要はなく、必要に応じてWicketを「通常の」MVCフレームワークとして使用することは非常に可能であることを強調したいと思います（もちろん、かなりのURLを取得するのは簡単です）。

Wicketプロジェクトは、コアWebフレームワークのみに焦点を当てており、特別なORMサポートやスキャフォールディングなどの特別な「優れた機能」はありません。私はここでWicketプロジェクトの哲学に個人的に同意しますが、フレームワークに来る新しい開発者にとって、ソート可能でページング可能なテーブルなどの「単純な」作業を行うことは、事前に構築されたコンポーネントが少し不足しているため、少し気が遠くなる可能性があります。Wicketの学習と生産性の曲線は少し急なものになる可能性がありますが、利点は、ニーズに合ったコンポーネント（および「動作」-より長いストーリー）を作成すると、それらが非常に再利用可能になることです。

私は個人的にWicketが大好きですが、Playを使用するのがおそらく最善であるという予感があります。あなたの質問は、Javaライブラリにアクセスできる「Django」が必要であることを示しています。その場合、Play（または他のJava MVC）が安全な選択だと思います。一方、Wicketがどれほど強力であるかを知らなかったために、Djangoを使用している可能性があります。;）プロジェクトについてさらに情報を提供していただければ、より適切な回答を提供できるようになります。

サイドノードとして：Playは（少なくとも今のところ）あまり主流ではないので、強力な商業的支援とさらに多くのすぐに使えるモジュールを備えたGrailsも検討したいと思います。

于 2010-11-10T23:17:32.870 に答える
18

遊ぶ！PythonやPHPなどのスクリプト言語を使用する開発者が快適に使用できるように設計されています。RailsやDjangoのように、独自のビルドシステムと管理スクリプトを提供します。既存のビルドツールとインフラストラクチャ（Javaランドで依存関係管理に一般的に使用されるMavenリポジトリなど）は、Playとうまく統合されません。

Wicketは、Javaでのデスクトップ開発から来る開発者にとってより快適になります。特別なツールは提供されていないため、必要に応じて特定のビルドツールに簡単に統合できます（Javaエコシステムで利用可能な自動依存関係の取得などを提供するビルドツールは多数あります）。

したがって、2つのオプションの間にはかなりの違いがあります:)どちらの経験が最も有益であるかを理解できれば、そこから決定はかなり明確になるはずです。

于 2010-11-10T20:03:44.983 に答える
7

システムがWeb層専用の場合は、Play！フレームワークは非常に適しています。But、データモデルがWeb専用ではなく、おそらくexported as REST by Spring with CXF、GWTまたは他のWebサービスによって消費され、Web層との一貫性のある状態を確認したい場合は、Wicket（Spring / hibernateを使用）が適切な選択です。

私がPlayについてあまり気分が良くない何か！キャッシュメカニズムです。キャッシュに手動で名前を付ける/挿入/取得/無効化/パージする必要があります。これにより、アーキテクチャ全体でエラーが発生しやすくなります。spring / JPA（hibernate）/ ehcache（または他のプロバイダー）を使用してウィケットを実行している間、上位層（web / REST ...）に一貫性のあるキャッシング/ daoレイヤーを定義できます。これにより、状態の不整合が発生しなくなります。

wicketのもう1つの利点は、Javaに裏打ちされたAJAXサポートが組み込まれていることです。これらのAJAXの状態はサーバー側で維持されますが（おそらく少し遅くなります）、JavaScriptを学びたくない場合でも、「それほど悪くない」AJAXページを作成できます。

Playで！、JSについて知らず、それを学びたくない場合、面倒なDOMを操作したくない場合は、「平均的な」サイトしか構築できません。OTOH、JS / jQueryに精通している場合は、Playを選択できます。。

于 2010-11-18T01:07:26.463 に答える
3

PLayを使用しています！たくさんあり、少しの評価のためにWicketを使用しました。私の経験では、Wicketで同じ作業を行うには、さらに多くのコードを作成する必要があります。Wicketを使用すると、より多くの「間接参照」が得られます。個人的には、「セレモニー」ができるだけ少なく、わかりやすいコードが好きです。

遊び！アーキテクトはPlay！にScalaサポートも追加しています。これは、ScalaがJavaコードおよびライブラリと完全に相互運用可能であるが、Javaよりもはるかに高度であるため素晴らしいアイデアだと思います。

于 2012-01-17T21:33:11.853 に答える