2

私は長い間 Java Web アプリケーションの開発者であり、私の経験では、Web アプリケーションを構築するための 2 つの主要なアプローチがあります。

最初のアプローチは、Struts、SpringMVC、JSF などのクライアントとサーバーを行き来するテクノロジーを使用することです。

2 つ目は、Flex、Swing (Web スタート)、JavaFX など、主にクライアント上で実行されるテクノロジを使用することです。

これらの 2 つのアプローチが長い間ここにとどまることはわかっており、それぞれに長所と短所があることもわかっています。

それぞれをいつ使用するのが好きですか？どちらかを選択する際に考慮すべきことは何ですか?

セキュリティ、アプリケーションの種類、ステートレス/ステートフル、DB 呼び出しなど、思いついたことを何でも言ってください。

さまざまな側面が何であるかを見るのは興味深いでしょう。

4

2 に答える 2

4

基本的に、区別は「シン」クライアントと「ファット」クライアントの違いです。

両方の長所と短所

ファット クライアント

  • より多くの処理ロジックをクライアントにプッシュして、サーバー リソースを軽減する機会。これにより、GUI が更新タスクを同時に実行できるため、ユーザー エクスペリエンスも向上します。
  • クライアントがオフラインで実行しやすい
  • よりリッチで複雑な GUI 機能を簡単に実装できる
  • ただし、さまざまなクライアント タイプ (デスクトップとモバイルなど) でロジックを再利用するのは難しい場合があります。
  • しかし、コードを作成するのが難しく、一般的なクライアント/サーバー Web 開発よりも専門的なスキルが必要であり、アプリケーション ロジックの多くがクライアントにコード化されるため、懸念事項の分離が少なくなる場合があります。
  • しかし、多くの場合、独自仕様 (フレックスなど)
  • ただし、データを Web クローラーに公開するのは難しくなる可能性があります

シン・クライアント

  • ビジネス ロジックは別の専門チームがサーバー側でコーディングしている間に、GUI 開発を別の専門チームに引き渡してコーディングすることができます (もちろん、これは問題のアプリの種類やロジックの場所によって大きく異なります)。
  • コーディング スキルがすぐに利用可能 (クライアントとサーバーの両方)
  • さまざまな GUI タイプまたは API にわたって、サーバー側でビジネス ロジックの再利用を促進します。
  • データは Web クローラーに簡単に公開される可能性があります
  • しかし、 GUIはユーザー エクスペリエンスを犠牲にしてインタラクティブ性が低下することがよくあります。
  • しかし、一般的にオフラインで実行することはできません

ただし、Chrome などのより強力なブラウザーの出現により、2 つの間の境界があいまいになっています。

一般的に言えば、別の要件 (高度なマルチメディアや処理のニーズ、またはアニメーションなどの特定の UI ルック アンド フィール デザインの選択など) が指示されない限り、デフォルトは常にサーバー上にビジネス ロジックを備えたシン HTML クライアント ベースのソリューションであると想定します。

于 2009-12-20T10:29:13.133 に答える
1

私のアドバイスは、すべての場合においてプラグインを避けることです。Web アプリに Java、Flash、Silverlight プラグインを使用しないでください。あなたはこれから先、傷だらけの世界に身を置くことになります。リッチ クライアントを構築する場合は、javascript を生成するものを使用します。Java が好きなら、GWT を使用してください。Java が好みでない場合は、ExtJS、Dojo、Sproutcore などの JavaScript ツールキットを調べてください。

トレードオフの見方：

シン クライアント (通常の HTML):

  • 利点: さまざまなブラウザやデバイスに簡単に適応できる
  • 利点: 低帯域幅のデバイスに適しています
  • 欠点: UI コントロールが少ない
  • 欠点: 往復時間が「フロー」を殺してしまいます。ユーザーがアプリで長時間作業することが予想される場合、このアプローチはうまく機能しません。

リッチ クライアント (GWT または JS ツールキット):

  • 利点: サーバー側はきれいな API だけを実装できます
  • 利点: UI デザインは実装が容易で、リッチです
  • 利点: 遅いラウンドトリップ時間に合わせて設計を計画できます (「オフライン」は、遅いラウンドトリップ時間の極端なケースです)。
  • 欠点: モバイル デバイスと低機能のブラウザ用に別のフロントエンドが必要
  • 欠点: 帯域幅が狭いと読み込みが発生するため、遅いユーザーはすぐに立ち去ります

私のアプリの場合、私は真っ向からリッチ クライアント キャンプに陥ります。しかし、私は「パブリック」インターネット用のアプリを作成していません。

于 2010-06-25T08:26:41.223 に答える