私は Java 開発者ではないので、いくつかの用語が間違っている可能性があります... しかし。
私が統合するアプリケーションは、Spring から Wicket に移行しています。それは私の統合に影響を与えるべきではありませんが、なぜ彼らがこれを行うのか疑問に思いましたか?
私の知る限り、Spring はより人気のあるフレームワークです。人気があること以外は何も知りません。私は Wicket のページを読みましたが、Wicket は本当にシンプルで分かりやすいようです。
Wicket の利点にはどのようなものがありますか?
フレームワーク全体を変更するのはかなりの作業になると思われるので、Wicket が Spring にはない何かを提供するのだろうか?
私が頻繁にサークルで宣伝されることが多い利点は次のとおりです。
Apache ウィケットの機能の一部を次に示します。
POJO コンポーネント モデル
Wicket のページとコンポーネントは、カプセル化、継承、およびイベントをサポートする実際の Java オブジェクトです。
開発の容易さ
Wicket は Java と HTML であるため、Java やお気に入りの HTML エディターに関する知識を活用して、Wicket アプリケーションを作成できます。
関心事の分離
Wicket はマークアップを Java コードと混同せず、マークアップ ファイルに特別な構文を追加しません。HTML と Java の世界は平行しており、HTML の属性と Java のコンポーネント プロパティである Wicket id によってのみ関連付けられています。Wicket HTML は単なる HTML であり、Wicket Java は単なる Java であるため、コーダーとデザイナーは、特別なツールに依存することなく、大部分独立して作業できます。
安全
Wicket はデフォルトで安全です。URL は機密情報を公開せず、すべてのコンポーネント パスはセッション相対です。セッション間で情報を共有するには、明示的な手順を実行する必要があります。さらに、URL 暗号化により、非常に安全な Web サイトが可能になります。
透過的でスケーラブルなクラスタリングのサポート
すべての Wicket アプリケーションは、クラスター上で自動的に動作し、追加の作業は必要ありません。ボトルネックが理解されると、Wicket はページ状態のレプリケーションの調整を可能にします。Wicket の次のバージョンは、ゼロステート スケーラビリティのクライアント側モデルをサポートします。
透明な戻るボタンのサポート
Wicket は、構成可能なページのバージョン管理をサポートしています。ユーザーがフォームを送信するか、ブラウザーの [戻る] ボタンでアクセスしたページからリンクをたどると、Wicket はページ オブジェクトを、ページが最初にレンダリングされたときの状態に戻すことができます。これは、戻るボタンをサポートする Web アプリケーションをほとんど手間をかけずに作成できることを意味します。
マルチタブとマルチウィンドウのサポート
Wicket は、マルチウィンドウとマルチタブの使用をサポートするアプリケーションを作成する簡単な方法を提供し、ユーザーが新しいブラウザー ウィンドウまたはタブを開いたときに開発者が適切に反応できるようにします
再利用可能なコンポーネント
Wicket の再利用可能なコンポーネントは、特に簡単に作成できます。Java extends キーワードを使用して既存のコンポーネントを拡張できるだけでなく、コンポーネントのグループを再利用可能なユニットとして関連付ける Panel コンポーネントを作成することもできます。
シンプルで柔軟なローカライズ可能なフォーム検証
Wicket でバリデーターを作成して使用するのは簡単です。また、検証エラー メッセージの表示と内容をカスタマイズしてローカライズすることも非常に簡単です。
タイプセーフ セッション
Wicket を使用すると、HttpSession 属性を手動で管理する必要がなくなります。ページおよびコンポーネント オブジェクトは透過的にセッションに格納され、アプリケーションはタイプ セーフなプロパティを持つカスタム セッション サブクラスを作成することもできます。セッションに保存されているすべてのオブジェクトは、クラスタリング レプリケーションに自動的に参加できます。
工場でカスタマイズ可能
Wicket は非常に拡張可能です。ほとんどの操作は、ファクトリまたはファクトリ メソッドを使用してカスタマイズできます。
着脱式モデル
Wicket のモデル オブジェクトは、クラスター内のメモリとネットワークの使用に関して非常に軽量です。モデルを使用すると、モデルを「アタッチ」して、永続ストレージから情報を取り込むことができます。モデルが使用されなくなったら、一時的な情報をリセットして、オブジェクトのサイズを縮小できます。
境界コンポーネント
Wicket Border コンポーネントを使用すると、再利用可能な方法でページを装飾できます。これは、一般的なナビゲーション構造またはレイアウトの継承に特に役立ちます。
すべての基本的な HTML 機能のサポート
Wicket は、イメージ タグ、リンク、フォームなど、Web アプリケーションの開発で使い慣れたものすべてをサポートしています。
属性のプログラムによる操作
Wicket コンポーネントは、任意の HTML タグ属性をプログラムで変更できます。
自動変換
フォームが検証されると、Wicket コンバーターを使用してモデルを更新できます。ほとんどの通常の変換は組み込みであり、新しいコンバーターを簡単に作成できます。
動的画像
Wicket を使用すると、画像の使用、共有、生成が非常に簡単になります。paint メソッドを実装するだけで動的な画像を作成できます。
ページング可能なリストビュー
Wicket の ListViews は非常に強力です。ListView の行には、他の ListView であっても、あらゆる種類のコンポーネントをネストできます。PageableListView は、大きなリストのナビゲーション リンクをサポートしています。
ツリー コンポーネント
ノードをナビゲートおよび選択するための既成のツリー コンポーネント。
ローカリゼーション
HTML ページ、画像、およびリソース文字列はすべてローカライズできます。
Spring は単なる Spring MVC ではありません。Wicketで Springを使用できます (おそらく使用する必要があります) 。
ウィケットロック！
Spring (Spring MVC と呼ばれる UI 部分) は、Spring (および Spring MVC と呼ばれる) を評価し始めたときに、巨大で扱いにくいように見えた、巨大で扱いにくいフレームワークのタイプである、「キッチン シンクを含むすべてを実行する」メガのようです。 MVC)。今日の春は、何か一つのことに集中しているようには見えません。もともとは単なる依存性注入フレームワークだったと思いますが、すぐにすべての人にすべてのものを提供しようとするようになり、単純さが失われました。
Spring について読んだ本には、あまりにも多くの XML 構成を含む例がありました。XML 構成ファイルのエラーは、デバッガーでシングル ステップ実行できる Java コードのエラーよりも、デバッグと修正がはるかに困難です。
とにかく、XML ではなく Java コードで何かを宣言することの何が問題なのですか? いずれにしても、すべてを XML で宣言する必要があると誰かが宣言したのはいつからですか? 複雑な XML 構成ファイルの海で泳ぎたい場合は、Spring を使用してください。仕事を終わらせて生産性を高めるのが好きなら、Wicket を選んでください。
Wicket は、Web アプリ開発に最適な Java ベースの UI フレームワークであることに重点を置いています。特定の依存性注入フレームワークや特定の永続化フレームワーク (JDO/JPA、DataNucleus、Hibernate などで使用します) にロックすることはありません。
焦点は明らかに UI にありますが、好きな依存性注入フレームワークを使用できます (Spring の DI を使用する必要はありませんが、必要に応じて使用できます)。Wicket で独自の DI ( http://www.expojo.com ) を使用することもあり、すべてがファンキーです。
Spring は Wicket よりも包括的なものです。
Wicket は Java Web UI フレームワークです。Spring には、永続性、リモート処理、セキュリティ、メッセージングなどのモジュールとともに、1 つもあります。
Spring は、依存性注入と AOP に基づいて構築されています。ウィケットにはどちらもありません。
私はそれを使用していませんが、それは単純なはずです。春が簡単か難しいかはわかりません。
Spring は、Web アプリケーション以外の多くの状況で有利に使用できます。
Wicket In Action の無料の最初の章で、Wicket を使用する利点について読むことができます: http://www.manning.com/dashorst/
要するに、Wicket は、開発中のアプリケーションが比較的複雑で、保守可能であり、チームをスケーリングして再利用できるようにしたい場合に最適なフレームワークです。オブジェクト指向プログラミングは、UI をプログラミングするための非常に有用なパラダイムであることが証明されましたが、残念ながら、Spring MVC を含む Web アプリケーションを開発するためのほとんどの Java フレームワークは、MVC という用語をタグ付けしてクールに聞こえるようにする非常に手続き型のプログラミング モデルしかサポートしていません (ただし、実際、MVC がサポートする粒度は、自己完結型のウィジェットではなく、要求/応答のラウンドトリップであるため、MVC は本当に誤解を招く可能性があります)。
Spring の DI 部分は素晴らしく、Wicket と一緒に簡単に使用できます。
これまでに提供された回答に同意します。言及されていないのは、Java コードに焦点を当てた Web アプリケーション開発の Wicket のアプローチの結果である次の点です。
この Java 中心のアプローチを取る他のフレームワークに出会ったことがありません。私が使用した他のすべて (Struts、Spring) には、JSP 開発が含まれます。
私にとって Wicket の大きな利点は、Java に重点が置かれていることと、Eclipse のような豊富な開発環境ツールが利用できることです。また、アプリケーションのプレゼンテーションの側面からビジネス ロジックが非常に明確に分離されています。
私が好きなWicketのいくつかの利点：
展開のしやすさ。
Spring はページ レベルでのみ MVC デザイン パターンを提供します。これは非常に粗いレベルの粒度です。対照的に、Wicket は個々のコンポーネント レベルで MVC 設計パターンを提供します (ファット クライアント プログラミングに対して Swing が提供するのと同じように)。Spring MVC では、フォームのすべてのデータがフロント サーブレット全体に対してグローバルであるため、情報の隠蔽、疎結合、緊密な結合の可能性はあまりありません。Wicket を使用すると、表示ロジックをよりモジュール化できます。componentA によって管理されるデータは、componentB のコードから見える必要はありません。
粒度が小さいほど、多数の異なる Web ページや Web アプリケーション間で表示コードを再利用することがはるかに容易になります。
また、コンポーネントの構成は XML ではなく Java で行われるため、実行時にオンザフライで構成でき、はるかに優れた機能と柔軟性を実現できます (ASP.NET Web などの他のほとんどのコンポーネント指向フレームワークとは対照的です)。 Forms または Java Server Faces)。
他の一般的な Java Web フレームワークに対する Wicket のもう 1 つの利点は、モジュラーで拡張可能な Web アプリケーションを作成できることです。これは、Web ベースの製品を設計している場合に特に役立ちます。これは、展開時にプラグインの形で機能とページを追加して拡張し、製品のコア機能/ソースへの影響を排除することによって拡張する予定です。ここにそれに関する非常に良い記事があります。