ApacheTapestryとApacheWicketの違い
Apache Wicket（ http://wicket.Apache.org/ ）とApache Tapestry（ http://wicket.Apache.org/ ）は両方のコンポーネント指向のWebフレームワーク-ストライプのようなアクションベースのフレームワークとは対照的に-ApacheFoundationによる。どちらも、Javaのコンポーネントからアプリケーションを構築できます。 どちらも私と非常によく似ています。
これら2つのフレームワークの違いは何ですか？誰かが両方の経験がありますか？具体的には：
- それらのパフォーマンスはどうですか、ステート処理はどのくらいカスタマイズできますかステートレスで使用できますか？
- コンポーネントモデルの違いは何ですか？
- どのアプリケーションに何を選びますか？
- Guice、Spring、JSR 299とどのように統合しますか？
編集：両方のドキュメントを読み、両方を使用しました。質問は、ドキュメントを読んでも十分に答えることはできませんが、しばらくの間これらを使用した経験から答えることができます。高性能サイトでステートレスモードでWicketを使用する方法。ありがとう。
私が見ているいくつかの関連する違い：
- Tapestryは、半静的ページ構造を使用します。この構造では、条件とループを操作して動的な動作を実現できます。 Wicketは完全に動的です。コンポーネントを動的にロードしたり、実行時に置き換えたりすることができます。これにより、Tapestryの最適化が容易になり、Wicketの使用がより柔軟になります。
- どちらのフレームワークも実行効率はほぼ同じですが、Wicketはサーバー側のストレージに依存しています（デフォルトでは、セッションの現在のページと、ファイルシステムのデフォルトの一時ファイルである「第2レベルのキャッシュ」の過去のページ）。それが気になる場合は、ピーク時に予想される同時セッションの数を検討し、セッションあたり約100kbで計算します（これはおそらくハイサイドです）。つまり、2GBでおよそ2万の同時セッションをサポートすることができます。他のことにもそのメモリが必要なので、15kと言います。もちろん、状態を保存することの欠点は、セッションアフィニティでのみうまく機能することです。そのため、Wicketを使用する場合の制限です。フレームワークはステートレスページを実装する手段を提供しますが、完全にステートレスなアプリケーションを開発している場合は、別のフレームワークを検討することをお勧めします。
- Wicketの目標は静的型付けを最大限にサポートすることですが、Tapestryはコード行を節約することを目的としています。したがって、Tapestryを使用すると、コードベースが小さくなる可能性が高く、メンテナンスに適しています。Wicketを使用すると、静的に型指定されることが多く、IDEでナビゲートし、コンパイラで確認するのが簡単になります。これはメンテナンスにも適しています。両方のimhoに言いたいことがあります。
Wicketは継承を通じて多くの機能を果たしていると人々が考えていることを、今までに何度か読んだことがあります。私はあなたに選択肢があることを強調したいと思います。コンポーネントの階層がありますが、WicketはIBehaviorのような構成を介して構成もサポートします（その上にWicketのAjaxサポートが構築されます）。その上、コンバーターやバリデーターのようなものがあり、それらをコンポーネントにグローバルに追加したり、Wicketが提供するフェーズリスナーのいくつかを使用した横断的関心事としても追加したりできます。
[〜＃〜]改訂[〜＃〜]タペストリー5を勉強した後。
Wicketの目標は、Web開発をデスクトップGUIと同様にする試みです。彼らはメモリ使用量（HTTPSession）を犠牲にしてそれを本当にうまくやった。
Tapestry 5の目標は、非常に最適化された（CPUとメモリ用）コンポーネント指向のWebフレームワークを作成することです。
私にとって本当に大きな落とし穴は、「Wicketはステートレスコンポーネントをサポートしています！」という応答でした。 「ウィケットはメモリが不足している」という議論に。 Wicketは確かにステートレスコンポーネントをサポートしていますが、それらは「Wicket開発の焦点」ではありません。たとえば、StatelessFormのバグは非常に長い間修正されていませんでした StatelessForm-検証が失敗した後のパラメータの問題 を参照してください。
- Wicketを使用するIMHOは、Webアプリケーションのパラメーターを最適化/微調整するまでは少し簡単です。
- Webアプリケーションをプログラムしていて、リクエスト処理の観点から考えたい場合、IMHOWicketの調査は困難です。
- Tapestry 5は、コンポーネントクラスを変更するとすぐに、コンポーネントクラスを自動的にリロードします。どちらのフレームワークもコンポーネントマークアップをリロードします。
- ウィケットフォースマークアップ/コード分離、タペストリー5はあなたにこの能力を与えるだけです。 Tapestry 5では、冗長性の低い構文を使用することもできます。いつものように、この自由にはさらに注意が必要です。
- Wicketのコアはデバッグが簡単です。ユーザーコンポーネントは継承に基づいていますが、Tapestry5のユーザーコンポーネントは注釈に基づいています。反対側からは、Tapestryの方がWicketよりも将来のバージョンへの移行が簡単になる可能性があります。
残念ながら タペストリー5チュートリアル 「t：loopsource = "1..10" ...」のようなタペストリーのコード例が悪い習慣になる可能性があることを強調していません。したがって、チームがそれほど小さくない場合は、タペストリーの使用規則/グッドプラクティスの作成にいくらかの努力を払う必要があります。
私の推奨事項：
- ページ構造が非常に動的で、ユーザーごとに10〜200 KbsのHttpSessionメモリを使用できる場合はWicketを使用します（これらは大まかな数値です）。
- リソースをより効率的に使用する必要がある場合は、Tapestry5を使用してください
これはIBMのDeveloperWorksからのかなり徹底的な比較です。
http://www.ibm.com/developerworks/Java/library/os-tapestrywicket/index.html?ca=drs
更新：リンクは無効ですが、ページは http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/Java/library/os-tapestrywicket）にあります。 /index.html?ca=drs
Wicketはよりシンプルなフレームワークだと思います。
また、Wicketでは、IDEのホットコード置換システムを介してクラスをリロードできます。 Wicketが現在実行中のアプリケーションのクラスの変更されたバージョンを実行するために必要なのはこれだけです。ホットコード置換には通常の制限が適用されます。たとえば、デバッグモード（Eclipse）で実行する必要があり、クラスの構造的側面を変更できない（つまり、クラス名、メソッドシグネチャの変更など）。
私はTapestryプログラミングモデルが好きではありません。多くの開発者が、開発における変更や非互換性が多すぎるためにTapestryを離れることを知っています。参照： http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
http://incubator.Apache.org/click/ を試してください。それは素晴らしいですJava Webフレームワーク。一部の人々はそれを「正しく作られたウィケット」と呼びます;-)
Wicketは非常に優れたWebフレームワークです。私が知っているすべてのことから最高です。私はバージョン1.3からそれを使用していて、常に欲しいものを手に入れています。 WicketはSpringとの優れた統合性を備えています。コードで@SpringBeanアノテーションを使用するだけで、SpringBeanをクラスに注入できます。
4.1が公式の安定版リリースだったときに言ったように：
タペストリーを使用する前に、タペストリーの開発履歴をよく確認する必要があります。 Tapestryは互換性のないアップグレードを多数行っており、古いバージョンのサポートは継続されていません。 4.1へのパッチは、妥当な時間枠内で処理されなくなりました。それは私の見解では、公式の安定バージョンには受け入れられません。
Tapestry 5の使用を確約するということは、次のことを意味します。
あなたはコミッターになるべきです。すべての新しい開発に遅れずについていく必要があり、古いバージョンをできるだけ早く放棄する必要があります。自分で安定したバージョンを維持します。