8

Wicket の単純さ (つまり、Wicket はより単純なシステムの私見) とクライアントでの GWT の応答性 (GWT のクライアント側の状態と JavaScript - 潜在的に複雑なクライアント側のコード) の議論とは別に、スケーリングに対する GWT のより大きな可能性についての議論は何ですか? Wicket で GWT を使用していますか?

個人的には Wicket の開発を数多く行ってきましたが、GWT についてはかなり前にざっと見ただけでした。

4

9 に答える 9

17

利点は、基本的に、GWT が JavaScript ベースのクライアントを構築するためのツールであることです。そのため、JavaScript ベースのクライアントが必要な場合に最適です。

Wicket はサーバーを中心としており、Javascript をステートレス ページに簡単に埋め込むことができますが、サーバー側の状態処理はより自然なアプローチです。

アーキテクチャが大きく異なることに注意する必要があります。

GWT を使用すると、アーキテクチャはクライアント サーバー (ブラウザ上のシック クライアント) に変わり、サーバーに対して「プロシージャ」(サービス) を呼び出し、データを送受信します。

Wicket (および JSF や Tapestry などの他のサーバー側中心のコンポーネント フレームワーク) では、アーキテクチャはより「伝統的な」3 層であり、送受信されるのはページまたはページの断片であり、純粋なデータではありません。

確かに両方をブレンドして他のアーキテクチャに適応させることはできますが、それはあまり自然なことではありません。

人々は「どちらが使いやすいか」(バックグラウンドに応じて完全に主観的なものです)、または「どちらがより美しく、より多くのコンポーネントを備えているか」に注目する傾向がありますが、アプローチに影響を与えるアーキテクチャの違いを過小評価してはなりません。セキュリティやスケーラビリティなどの側面を処理する必要があります。

于 2009-10-02T20:12:11.983 に答える
10

過去数か月間、GWT ベースのプロジェクトに携わってきました。私は何年も Wicket 開発チームの一員であり、変化を楽しみにしており、GWT (私は常にもう 1 つの優れた Java フレームワークとして宣伝してきました) に多くのことを期待していました。

正直なところ、GWT の操作に関してはがっかりしています。私は、実際には私のチーム全体が生産性に大きな打撃を受けたと感じています。理論的には、GWT は優れています。しかし、フレームワークの癖と制限、平凡なエラー報告 (特にシリアライゼーション エラーの場合)、長いコンパイル時間 (3 分から 10 分の間であり、私たちのプロジェクトはまだそれほど大きくはありません) を考慮に入れると、すべてが完了しても、すべてのブラウザーをテストし、微調整と回避策を見つける必要があるという事実、それが大量の初期ダウンロードを生成するという事実 (ほぼ MB、徐々に削減していますが、多くの場合など）など、Wicket の方がはるかに簡単かつ迅速に作業できると思います。

私は GWT での作業が嫌いではありません。それでも、ほとんどの Java フレームワークよりもはるかに優れています。それを使って作業することで、もっと多くのことを期待しただけです。私はそれがおそらくWicketよりも優れているとさえ思っていました. しかし、結局のところ、それは私見ではありません。願わくば、GWT 2.0 が多くのことを改善し、Eclipse プラグインの癖のいくつかもすぐに正されることを願っています。

于 2010-01-31T23:18:10.120 に答える
3

GWTに対するWicketの利点の1つは、Javascriptが有効になっていないクライアントにフォールバックを提供したい場合にWicketが処理できることです。GWTはJavascriptに完全に対応しており、Wicketを使用すると正常に機能を低下させることができます。

于 2010-04-29T19:11:24.563 に答える
3

GWT を wicket (または同様) と比較するのは公平ではありません。なぜなら、それらは実際には 2 つの異なる陣営から来ているからです。前者は JavaScript フロントエンド アプリケーションを構築するためのフレームワークであり、後者は従来の Java Web アプリケーション フレームワークです。

したがって、以下のポイントは GWT と wicket の比較ではなく、高度な JavaScript/AJAX Web アプリケーションに GWT を使用することを決定したときにコンパイルされた一般的なリストです。

  • Java での開発を可能にし、JavaScript のブラウザー固有のフレーバーに自動的にコンパイルすることにより、JavaScript とクロスブラウザー サポートの欠点を隠します (これは、漏れやすい抽象化の法則により完全に真実ではありませんが、GWT が最初に作成された主な理由です) -制約を楽しむを参照してください);
  • Java は、高度な JavaScript/AJAX UI になると、多くの Java 開発者に好まれます。
  • Java 開発環境とツールが完全にサポートされています。Eclipse プラグイン、デバッガー、リファクタリング、Eclipse のホスト モード。
  • JUnit テストは、モック オブジェクトとホスト モードの両方でサポートされています。
  • Java バックエンド (GWT-RPC) とのクリーンな統合。
  • 統一されたルック アンド フィールの比較的豊富な UI ウィジェットのセット。
  • サードパーティ製のウィジェット、フレームワーク、パターン、およびサンプルの利用可能性 (まだ制限があり、長いウィッシュ リストがあります)。
  • Google のサポートは、フレームワークのより広い受け入れ/人気と急速な進歩の両方を促進します。
  • 1.6+ および今後の 2.0 リリースで成熟するフレームワーク: (イベントバス、イベント ハンドラー、MVP パターンを使用した GUI アーキテクチャ、コンパイラーの最適化など)。
于 2009-08-15T04:48:23.207 に答える
2

私の意見では、GWT の最大の利点は、Java という 1 つのプログラミング言語で作業できることであり、Java がもたらすすべての利点を備えています。

CSS と共に、それらは強力なペアを形成します。

別の言い方をすれば、Javascript と HTMLをほとんど忘れることができます。

それが利点であるかどうかは、ほとんどの場合、スキルと要件によって異なります。これと同じ議論が社内で行われ、最終的に 1 つのチームが Wicket と別の GWT を選択しました。

于 2009-07-29T20:37:43.067 に答える
0

GWT の背後にある優れた点は、Java だけで作業できることです。彼らは RPC で素晴らしい仕事をして、プログラマーにとってほぼ透過的にしました。クライアント側とサーバー側が完全に定義されたアプリケーションではなく、デスクトップ アプリのようにコーディングしていると感じることがよくあります。

于 2009-08-17T20:16:47.650 に答える
0

私が見つけたGWTに対するウィケットの他の利点はほとんどありません。

  1. GWT は、javascript が無効になっているブラウザでは動作しません。（これはまれですが）。JavaScript が利用できない場合、Wicket は常に通常の http リクエストにフォールバックします。
  2. GWT アプリケーションは 1 ページ アプリケーションであるため、ブックマークやブラウザー タブの使用が少し難しくなります。wicket を使用すると、1 ページ アプリケーションまたは複数ページ アプリケーションの作成を選択できます。必要に応じて、ページをブックマーク可能にすることができます。
  3. GWT では、独自のコンポーネントを作成することは必ずしも容易ではありません。ウィケットでは、生の html、css、さらには javascript を使用しているため、カスタム コンポーネントの作成は非常に柔軟です。既存の jquery または dojo コンポーネントを非常に簡単にラップすることもできます。
  4. GWT では Java を JavaScript にコンパイルする必要があるため、GWT コンパイラによってエミュレートされた Java クラスのみを使用できます。これは制限になる可能性があります。Wicket はサーバー側のフレームワークであり、必要なすべての Java を使用できます。
  5. GWT の wicket を使用すると、CSS や Web デザイナーとの作業がはるかに簡単になります。
于 2011-10-12T16:36:38.307 に答える