web-dev-qa-db-ja.com

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

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

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

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

そのため、Amazon Fulfillment 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）の開発に集中するのは今が良い時期ですか？

javascriptarchitectureasp.netteamenterprise-architecture
9
Mag20

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

6
Htbaa

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

4
TMN