1

クライアント側で行われるWebアプリケーションの作業はますます増えています。UI操作、入力事前検証（もちろん、検証の最後の手段としてではありません）、ウィジェット、エフェクトなど。

Javascript / GWT /その他で記述されたドメインロジックをクライアント側に配置することにした場合はどうなりますか？サーバーはデータベースインフラストラクチャを提供するだけです。

これはあなたにとって実行可能に聞こえますか？このアイデアに対する経験、アドバイス、意見はありますか？

編集：ざっと見てみると、php / python / java/whateverの1行なしでアプリケーション全体を作成できることがわかります。

4

7 に答える 7

1

私はここにある他のポスターに敬意を表して反対します。実際、私はほぼ完全にクライアント側のロジックを使用して、まさにそのようなスクラブルボードゲームを実装しました。実際、クライアント側をさらに集中させるためにやりたいことがたくさんあります。Gmailは、クライアント側で膨大な量の作業を行います。

ただし、実際的な理由から、サーブ側で管理する必要があるものがいくつかあります。たとえば、サーバーはユーザーにいくつかのタイルを与える必要があり、ユーザーはそれらのタイルを配置した場所をサーバーに伝えることができ、サーバーはクライアントを完全に信頼できないため、サーバーはそれらのスロットが空であることを確認する必要があります（クライアントは常にハイジャックされる可能性があります） 、スクリプトを介さない場合は、HTTPトラフィックをスニッフィングして変更します）。

多くのテクノロジーがあります。たとえば、RESTfulインターフェイスを介してDB内のCRUD操作を公開するADO.NET Data Servicesや、JavaScriptを介してデータオブジェクトを直接保存/管理するCouchDBなどです。また、jQueryやMoo Toolsのような豊富なクライアントサイドライブラリは、クライアントにますます多くのことを実行するように促しています。

そして、あなたがそれについて考えるならば、フラッシュはクライアント側ですべてのUIとインタラクションのことをすることについてたくさんあります。一部のAdobeFlexアプリケーションは素晴らしいです。私は最近、グラフやピボットなどをクライアント側でレンダリングするGoogleアナリティクスに1つ使用しました。サーバーはデータを提供するだけです。それでも、Google GearsとFirefox（3.2だと思いますか？）はクライアント側のストレージを提供するようになり、切断されたアプリケーションのシナリオがさらに面白くなりました。

于 2009-05-01T20:43:57.563 に答える
0

これらはすべて素晴らしいことですが、誰かがjavascriptを無効にした場合、ユーザーがデータベースを台無しにする前に、それを処理してサーバー上の入力を検証できる必要があることを覚えておいてください。したがって、クライアント側に必要なものを配置できますが、サーバー側でも確認する必要があります。

于 2009-05-01T18:45:45.850 に答える
0

私の意見では、これは実行可能なアイデアではありません。これにはいくつかの理由があります。

  1. 古いブラウザを使用しているためにユーザーがこれらのクライアント側の機能を持っていない場合はどうなりますか？Webサイトはおそらく機能しません。
  2. 常に、入力の検証とクライアントでのルールチェックのために、サーバーで常に同じチェックをすべて実行してください。そうしないと、Webサイトに重大なセキュリティ問題が発生します。ユーザーは、すべてのjavascriptチェックをバイパスして、データベースに対してやりたいことを何でも行うことができます。

全体として、クライアント側のコードは、Webページの感触よりもアプリケーションのような感触をユーザーに提供するのに非常に便利ですが、Webサイトのセキュリティとアクセシビリティのために、2つの手法を両方とも実装する必要があります。

于 2009-05-01T18:46:23.587 に答える
0

パブリック (および非パブリック) Web アプリケーションの場合、誰かが防御をチェックしようとするのは時間の問題です。JavaScript の検証が最初に行われます。ブラウザで無効にすることも、アプリケーションで作業中に無効/有効にすることもできるため、望ましい効果が得られます。

実際には、3 つのレベルの検証が必要です。

  1. UI 検証 (オプション): ユーザー入力の初回チェック。サーバー ラウンドトリップなしの迅速な応答 -> ユーザーは満足している + サーバーは、無効な要求から解放されたことに満足しています。

  2. サーバー側の検証 (必須)。ここで、すべての検証とビジネス ロジック ルールが再び行われます。必要なことを確認/検証/実行するには、標準またはサードパーティのライブラリにアクセスする必要がある可能性があります。ここでは、BL レベルでデータの整合性を実現します。

  3. データベース レベルの検証 (非常に望ましい)。防御の最後の境界線。外部キー/一意キーなどの使用によるデータの完全性の保証。制約+複数の並列リクエストからのトランザクションレベルの保護により、BLレベルの整合性が突然破壊されます。

あなたがそれを正しくしたいのであれば、それはそうあるべきです。

于 2009-05-03T15:47:17.930 に答える
0

ここで、Web アプリのパフォーマンス分析に関する優れた要約を見つけることができます: http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

要するに、最新の Web アプリケーションは、100 ミリ秒のパフォーマンス向上に苦労しています。このような短い期間では、http レイテンシーに依存することはすでに問題になっています。そのため、ユーザーとやり取りするときの http 呼び出しの数を減らすためだけに、多くのロジックがクライアント側に移動しています。

複雑なクライアント側コードの構築に役立つ、利用可能で開発中のフレームワークが多数あります。手始めに: jQuery (UI)、Dojo、MooTools、Prototype など - これらはより一般的なフレームワークであり、あらゆる種類のクライアント側ロジックに適しています。

より正確に：

ここには、さまざまなフレームワークの包括的な概要がありますhttp://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

于 2012-04-22T12:52:43.883 に答える
0

少なくとも一貫性とスピードを目指しているのであれば、それは現実的ではないと思います。Javascript に多くのロジックを入れると、ブラウザに多くの作業が発生します。つまり、SLOW クライアントです。また、すべてのブラウザにはちょっとした癖があることを忘れないでください。

于 2009-05-01T18:47:54.190 に答える
0

アプリケーションと、それをどのように使用してコードを再利用するかによって異なります。

クライアント側の JavaScript は、Web ブラウザーに固有のものです。

ドメイン オブジェクトとエンティティは、他のアプリケーション (デスクトップ、Web サービスなど) で再利用できます。

言うまでもありませんが、アプリがいつ大きくなった場合でも、ダウンロード時間はどんどん長くなります。

もちろん、誰でもすぐにコードをコピーして貼り付け、アプリを複製できます。

于 2009-05-02T08:32:04.913 に答える