ビジネスロジックは本当にサーバーに属していますか？

Webアプリケーションの一般的なスタックは、データベース、サーバーサイドコードを備えたサーバー、HTML / CSS / JavaScriptを備えたブラウザーを備えたユーザーです。

広範なAJAXが登場する前は、コントローラーがサーバー側コードであるMVCが決着していました。サーバーは動的Webページ（つまり、JSPやASPなどのテンプレート化されたHTMLソリューション）に対する応答要求をルーティングする必要がありました。サーバーは、データベースへの呼び出しを調整し、ページ要求への応答に使用する動的ページを決定します。これらすべての結果、ビジネスロジックはページを提供するという考えに強く結び付けられていませんが、サーバーには最終的にビジネスロジックが含まれています。

「Web 2.0」に移行すると、サーバーサーバーの静的ページは、JavaScriptを使用してデータを入力し、表示内容を変更します。JavaScriptに含めることができます。JavaScriptは多くの場合、RESTfulサービスを実装しています。つまり、データベースクエリを指定しています。

したがって、サーバーは、実際のファイルを提供し、AJAX呼び出しに応答する役割に任されています。また、AJAX呼び出しへの応答は、セッション管理とセキュリティの提供にすぎません。そして実際、ユーザーが見ることができるのは、データベースで指定されるべきデータです。

そこで、そこから、サーバーを、電子メールの送信やWebサービスの起動など、たまにしか行わない、ダムの仲介者の役割に追いやるべきですか？ビジネスロジックがすべてJavaScriptに存在する（秘密でない場合）か、それがストアドプロシージャに存在する可能性がありますか？

サーバーとデータベースを組み合わせたり、SAPのようなERPソリューションをサーバーとして機能させることは理にかなっていますか？

セキュリティ上の理由から、ビジネスロジックはほとんどの場合、ユーザーが制御するサーバー上で実行する必要があります。「サーバー」が「Webサーバー」を意味する場合、私は同意します。ビジネスロジックはほとんど必要ありません。しかし、ほとんどの場合、ビジネスロジックを備えたアプリケーションサーバーが必要です。それがデータベースまたはWebサーバーの内部にあるか、独立していてWebサーバーによって呼び出されるかに関係なく。

WebサーバーがWebサービスまたはJSONを介してアプリケーションサーバーのAPIを公開するだけの実際のアプリケーションがあります。

Web 2.0およびAJAXの前でも、ビジネスロジックとASPページを混在させることはベストプラクティスとは見なされていませんでした。独立したビジネスロジックを使用し、プレゼンテーションロジックのサーバー部分をASP、JSP、またはその他のものにすることをお勧めします。したがって、Web 2.0からの本当の変更は、プレゼンテーションレイヤーを完全にJavaScriptにできることです。個人的にはそれが好きです。

JavaScriptは多くの場合、RESTfulサービスを実装しています。つまり、データベースクエリを指定しています。

これはあなたが間違ったところです。RESTはCRUDではありません。

RESTによって公開されるリソースはデータベースレコードではありません。これらは、ビジネスロジックに従って動作する完全に管理されたオブジェクトです。サーバーがPOSTまたはPUTを受信した場合、サーバーは検証と保存だけを行うべきではありません。アプリケーションに適したものを実行する必要があります。

簡単な例：Twitterのようなアプリは、特定のコンテナーでPOSTメッセージとしてツイートを受け取ります。次に、サーバーはコンテキスト（「あなたは誰ですか？」、「どのチャネルですか？」）とコンテンツ（「ハッシュタグ？」、テキストインデックスなど）を分析し、すべてをそれぞれのキューに格納します。おそらく、すべてのフォロワーに直接参照を追加します。

これは、単にリソースをコンテナーに追加するだけでなく、ビジネスロジックによってすべて定義される多くの作業です。そして、それはサーバーに属しています。

このアプローチに対する私の懸念は、設計の誤解に起因している可能性があるため、遠慮なく私を撃ち落としてください。

ただし、製品の拡張性、保守性、およびセキュリティについて検討してください。

製品が大幅に成長するとデータベースがボトルネックになるため、「パフォーマンス」はビジネスロジックをストアドプロシージャに組み込むことを提案しますが、データベースサーバーに追加のCPU負荷をかけ、サーバーが最大容量に達した日を早めます。Webサーバーとは異なり、ACIDデータベースは並列ハードウェアを使用して簡単にスケールアップできません。製品がそれほど成功しない場合、これは問題ではありません。

異なるブラウザーが異なるjavascriopt、ブラウザーの複数のバージョンなどを要求するwebbrowswersで実行されているjavascriptでビジネスロジックを維持することの考え...なぜこの問題を今よりも複雑にするのですか？

しかし、Javiarが言ったように、RESTアプローチを製品のデータベースAPIとして使用することは、あまり賢明ではありません。RESTインターフェースの利点は、他の人々がRESTインターフェースを使用してクエリするさまざまな方法を考えることです。ただし、これはパブリックポストビジネスロジックリソースであり、低レベルのテーブルレコードリソースではありません。このような低レベルのデータクエリをHTTP APIで利用できるようにするという考えは、セキュリティの悪夢のように聞こえます。

これについては多くの考え方がありますが、確かに普遍的に「正しい方法」と呼ぶことができる方法はありませんが、他のすべては普遍的に「間違った方法」ですが、サーバー側でビジネスロジックを分離する理由はいくつかあります。 、RESTfulサービスを介してこれらのオブジェクトとサービスにアクセスします。

簡単に言えば、それは主にリスク管理、およびパフォーマンスの監視と改善に関することです。

詳細に：

一番の最大の理由はセキュリティです。クライアントは、ガベージ以外のものをサーバーに送信することを信頼すべきではありません。サーバー側のセキュリティの側面を維持することにより、悪意のあるユーザーがシステムに損傷を与える潜在的なリスクを切り分けます。JavaScriptは完全にクライアント側であり、簡単に変更できるため、出力を信頼することはできません。

2番目の理由は、懸念の分離です。あなたのJavaScriptプログラマはセキュリティの専門家ではないかもしれませんし、あなたのセキュリティの第一人者はJavaScriptでそれほど優れていないかもしれません。ビジネスロジックをプレゼンテーションロジックから分離することで、JavaScriptがその許可レベルを超えてリソースにアクセスすることを許可されず、エラーが発生するので、これらの問題を回避できます。その処理はスクリプトプログラマーの裁量の範囲内です。同様に、セキュリティ担当者は、セキュリティがどのように維持されているかを確認するためにJavaScriptをデバッグしません。

3番目の理由はパフォーマンスです。ビジネスロジックは、サーバーおよびデータベースリソースを要求する可能性があります。そのロジックをUI要素から分離しておくことで、アプリケーションのその部分だけをスケールアウトでき、ボトルネックへの対処がはるかに簡単になります。さらに、ビジネスプロセスがサーバーで実行されている場合、システムまたはデータベースのバックエンドをロードしているビジネスプロセスを特定するのがはるかに簡単です。

ここでの当然の結果として、多くの場合、複数のビジネスプロセスが同じデータを使用するため、サーバー側にキャッシングを実装して、クライアント側にコードアクセスを許可することができない/安全でないシステム全体の負荷を減らすことができます。

最後に、ACID標準を維持するために、ビジネスロジックは実際にサーバー上に存在する必要があることを提案します。サーバーへのデータベース接続のみで、Webブラウザーで実行された課金製品を維持していることを覚えています。毎日の請求（良い日には1時間以上かかる可能性があります）が中断された場合、たとえば、ブラウザが閉じられたかクラッシュした場合、データベースから作成された混乱を整理するのに数時間かかることがありました。矛盾した状態。これにはクレジットカードも含まれるため、請求記録もプロセッサと照合して確認する必要がありました。

アプリケーションレベルまたはデータベースレベルでトランザクションを維持するための任意の言語のフレームワークがあるため、サーバー側のビジネスロジックは、ほとんどの場合、ACIDの更新を保証するのに簡単です。Webクライアントからの複数の更新を介してこれを行っている場合...ある時点で矛盾した状態になり、アプリケーションに影響を与える可能性があります。

RESTfulサービスを単なるデータベースへのアクセス方法と考えるのは魅力的ですが、災害に備えてこのトラップに陥らないでください。RESTfulサービスを介して公開するオブジェクトモデルはデータベースに関連付けることができますが、CRUDエンジンとして使用するだけでなく、実際にビジネスロジックをカプセル化する必要があります。