すべてのUIロジックをクライアント側に移動しますか？

9

私たちのチームは当初、JavaScriptの専門知識が最小限のサーバー側開発者で構成されていました。ASP.NETでは、コードビハインドで、または最近ではMVCのコントローラーを介して多くのUIロジックを記述していました。

少し前に、2人の高レベルのクライアント側開発者がチームに加わりました。HTMl / CSS / Javascriptで、サーバー側のコードとサーバー側のWebコントロールを使用してこれまで実行できたことのほとんどすべてを実行できます。

コントロールの表示/非表示
検証を行う
AJAX更新の制御

：私はそれを考え始めので、多分ちょっとアマゾンフルフィルメントAPIのように、私たちのビジネスロジックの周りにハイレベルのAPIを作成する方が効率的でしょうhttp://docs.amazonwebservices.com/fws/latest/APIReference/、そのクライアントので、サイド開発者はUIを完全に引き継ぎ、サーバーサイド開発者はビジネスロジックのみに集中します。

したがって、注文システムでは、次のような高レベルのAPIを使用します。

OrderService.asmx

CreateOrderResponse CreateOrder(CreateOrderRequest)
AddOrderItem
AddPayment
-
SubmitPayment
-
GetOrderByID
FindOrdersByCriteria
...

APIへのJSON / RESTアクセスがあるため、クライアント側のUIから簡単に利用できます。このAPIを使用して、内部UI開発とサードパーティが独自のアプリケーションを作成することもできます。

Javascriptの進歩と優れたクライアント側開発者の可用性により、コードビハインド/コントローラーを取り除き、クライアント側開発者が消費できる高レベルAPI（ala Amazon）の開発に集中するのは今が良い時期ですか？

— Mag20
ソース

6

サーバー側の負荷を軽減し、アプリケーションの応答性を高めるためのクライアント側の検証は問題ありませんが、常にサーバー側の検証を行います。JavaScriptをオフにすることができ、REST APIを直接使用する場合、JavaScriptは必要ありません。

— HTBAA
ソース

はい、検証もドメイン/ APIの一部になります。クライアント側は、APIから検証する必要があるものをプルするか、各メソッドに必要なものなどを文書化します。クライアント側からの送信でまだ検証エラーがある場合-例外をスローします。

— Mag20、2011

4

注意すべき点の1つは、複雑なUIでは、階層、マスター/詳細関係、およびビジネスレイヤーには実際には存在しないその他のUI概念などをサポートするために、追加の「UIアシスト」レイヤーが必要になる場合があることです。多くの場合、ビジネスレイヤーへの複数のラウンドトリップを行わずにこれらの機能の一部を実装できないため、パフォーマンスが低下します。少なくとも、UIにデータベースへの直接アクセスを提供するよりも「UIアシスト」レイヤーを使用することを好みます。

— TMN
ソース