理想主義者向けのビジネスロジックはどこにありますか？

この記事では、自分自身と私の議論を理解しようとします。 そもそも、Habréで見つけた翻訳の記事の著者に反対しようとします。 息子のビジネスロジックはどこにありますか？ 。 彼女は私が10年前と同じ理想主義者によって書かれました。 したがって、本質的に、この記事では自分自身と議論します。 実際、私が開発するアプリケーションが増えれば増えるほど、より美しい理論が理想的なスキームに適合しなくなります。 理想的な回路は、単純であるという点で優れています。 ビジネス層はどこですか？ また、クライアント側またはサーバー側で簡単に言うことができます。 混合すると、彼の鼻を鋭くねじって「たわごとコード」と言います。 私はこれに同意しません。 現実の世界では、理想主義的な概念に投資することはありません。むしろ、それを詰め込むことはできますが、すぐに失われます。 そのため、最初は無意識のうちに、さまざまなケースがあることに気付きました。 そして今、私はビジネスロジックの配置に関するこの決定またはその決定に影響を与えるものをますます定式化しようとしています。 ここでは、単純な解決策を求めている若いユートピアへの議論のない美しい理論を残しています。

データベースに照らしたオブジェクトおよび手続き型プログラミング

この記事の著者は次のように書いています。

...ビジネスロジックとは何かを明確に定義しましょう...データベースサーバーはストレージ層です。 データベースは、可能な限り最高の効率でデータを保存、取得、更新するように設計されています... データベースは、買い手がどのテーブルを保存するべきかを判断できず、買い手に注意を払わずにテーブルを操作する必要があります。 データベースのタスクは、顧客を説明するテーブルに行を格納することです。 カスケード整合性、データ型、インデックス、空の値などの基本的な制限に加えて、データベースには、顧客がビジネスレイヤーで何をしているのかに関する機能的な知識がありません。

定義としてそれについて書いています。 そして彼は、彼がクライアントサーバーアーキテクチャについて話すときだけそれを正当化します：

すぐに、ほとんどのビジネスロジックをサーバーに移動することにより、ネットワークの負荷を軽減し、ロジックを集中化して固定展開コストを削減できることが明らかになりました。 アーキテクチャ的には、サーバーはクライアントサーバーシステムで十分に準備された場所でしたが、プラットフォームとしてのデータベースはほとんど機会を提供しませんでした。 データベースはストレージと配信用に設計されており、そのアーキテクチャにはビジネスロジックの方向への拡張の可能性が含まれていませんでした。 データベースストアドプロシージャ言語は、基本的なデータ変換用に開発され、SQLに欠けていたものをサポートします。 ストアドプロシージャ言語は、複雑なビジネスロジックタスクを処理するためではなく、高速実行のために開発されました。

ほとんどの場合、中間リンクは接続プールを管理するためだけに存在しましたが、場合によっては、開発言語（C ++、VB、Delphi、Java）がストアドプロシージャ言語よりもビジネスロジックの実装に適しているため、ビジネスロジックが中間リンクに移動し始めました。 すぐに、中間リンクがビジネスロジックに最適な場所であることが明らかになりました。

したがって、矛盾が続きます。 「 開発言語（C ++、VB、Delphi、Java）がビジネスロジックの実装により適していたため、ビジネスロジックが中間リンクに移行し始めました 。」 しかし、前述の開発言語のどのような特性が手続き型言語のSQLよりも優れていますか？ SQLには、条件とループ、プロシージャへの分割もあります。 このSQLは、オブジェクト手法が有効になるまで、C ++、VB、Delphiなどの手続き型言語と変わりません。 したがって、「ストアドプロシージャの言語は、ビジネスロジックの複雑なタスクを処理するためではなく、迅速な実行のために開発された」という文は非常に表面的であり、非常に物議を醸しています。

手続き型論理制御の観点から見ると、SQL言語は他の言語と変わりません。 しかし実際には、より複雑なロジックを管理できるオブジェクト方法論を実装していません。 したがって、ここからは、オブジェクトメソドロジを使用してビジネスロジックを管理しない場合、アルゴリズムをSQLまたはCで記述することに注意する必要はないと主張します。 したがって、いわゆるサーバーがサーバー上にあるかどうかに違いはありません。 中間層がCであり、これをストレージとして使用してデータベースにアクセスするとします。または、データテーブルにもアクセスするSQLストアドプロシージャがデータベースにあるとします。 後者は、 余分な層を排除します。

しかし、これはすべて非オブジェクト言語にのみ当てはまることを強調します。 オブジェクトの方法論から利益を得たい場合にのみ、データベース内のデータをビジネスロジックから分離し、ビジネスロジックをSQL以外の言語で個別に管理します。

リレーショナルデータベースモデルは、ビジネスロジックの一部です。

記事の著者が次のように書いています。「 データベースサーバーはストレージレベルです。データベースは、可能な限り最高の効率でデータを保存、受信、更新するように設計されています。データベースは、買い手がどのテーブルを保存すべきかを把握できず、買い手に注意を払わずにテーブルを操作する必要があります。 「-完全に正確ではありません。 もちろん、データベースサーバーはデータを保存するタスクを実行しますが、これが唯一のタスクではありません。 データ処理は、データベースサーバーでも実行されます。 著者は、データの処理を1つのテーブルの基本操作の挿入、更新、削除に減らし、他のすべては分離する必要があるビジネスロジックであることを伝えたいと考えています。

しかし、彼はデータモデルの実装がいわゆるデータを表していることを忘れています。 データストレージの冗長性を排除するための3番目の標準形式。 これだけでも、データベース内のデータが1つのテーブルに格納されているのではなく、一連のテーブルでリレーショナルに分解されていることを示しています。 また、1つのテーブルのみを使用して「バイヤー」に関するデータを更新することは絶対にできません。 著者は、オブジェクトの方法論について直接話すのではなく、「オブジェクト購入者」という言葉を使用します。 購入者オブジェクトが購入者テーブルに直接対応していないと言う必要はないと思います。 買い手オブジェクトは通常、結合テーブルのセットからの複雑な選択で選択されます。 しかし、彼はどのようにして買い手のオブジェクトのデータの更新を提示しますか？ 彼は、SQLの単一テーブルでの作業に制限があるビジネスロジックで、リレーショナルデータを格納するロジックを処理しますか？ 顧客のオブジェクトのデータを複数のリレーショナルテーブルに格納するこのロジックは、明らかであり、1つのストアドプロシージャで実装する必要があります。

また、データベーステーブルに格納されているデータがプライマリデータであり、処理またはユーザーへの表示のためにデータから取り出すデータはセカンダリデータであることに同意する必要があります。 したがって、ビジネスロジックについて話すときは、リレーショナルデータモデルを開発したときに、ビジネスロジックのルールの一部を既に設定していることに注意する必要があります。 データストレージモデルは、ロジックのビジネスモデルに特定の条件を既に課しています。 ストアドプロシージャの助けを借りて、データの格納方法を抽象化し、リレーショナルテーブルではなくオブジェクトという意味で外部データを提供できます。 その後、ビジネスロジックはオブジェクト方法論のセカンダリデータで機能します。

これらの2つのセクションでは、今のところ、著者が主張している過剰な部分を削除しただけで、彼のフォロワーがいると思います。 次に、さらに進んで、どのケースでビジネスロジックを操作するためにオブジェクト手法を使用するのが効果的であり、効率的でないかを確認します。

理想主義者の世界を揺さぶる

上記の修正により、リレーショナルデータモデルとビジネスロジックのビジネスモデルを分離して、非常に多くのアプリケーションを実装しました。 しかし、私の細い世界はかつて大きく揺れました。

私が実装したアプリケーションの1つは、銀行での支払いシステムの実装でした。 基本的に、これは支払い注文フォームを表す1つのフォームです。 とりわけ、このフォームは、いわゆる 関連するコンバージョン。 さらに、変換は異なる可能性があります：支払いに十分なお金がない場合は、別の通貨から変換することを提案する必要があり、支払いの金額と手数料は異なる通貨から変換することができ、支払いのために当座貸越しを行い、関税を変換することができ、あなたが持っているものを部分的に支払うことができます不足額などを変換する 非常に複雑なビジネスロジックは、非常に厳密にユーザーインターフェイスと織り交ぜられています。

しかし、ある顧客は、ある日、支払い注文をシステムで自動的に処理して実行することを望み、銀行員との対話で変換を作成したり、当座借越をするのに十分なお金がなかった場合、支払い注文がいくつかの要件を満たしているかどうかを確認する必要がありました、ただし、今回は銀行の従業員をこのプロセスから完全に除外する必要がありました。 通貨の優先順位が確立されました-どの順番で、どのような場合に、何とどのように許可され、どのような場合に検査のために銀行員を与えるか。 目標は、銀行員が支払注文の確認作業から完全に解放された場合の90％で理解できます。

そのため、簡単な質問が発生しました。90％のケースで、ユーザーの対話はもはや必要ではありませんでした。 以前にユーザーインターフェースをビジネスロジックから適切に分離したと仮定する場合、ビジネスロジックはオブジェクトの複雑なセットに既に実装されています。 唯一の問題は、このビジネスロジックの開始がユーザーの対話によって導かれたことです。 そして、データベースから支払い注文を選択し、ユーザーダイアログによる開始ロジックを別の自動処理ロジックに置き換え、既存のロジックで処理し、支払い注文をデータベースに書き戻す必要がありました。 さらに、支払注文の転記は、残高の自動作成と別の複雑な手順です。 そして、変換、当座貸越を忘れないでください。これは、もちろん、別の文書や他の記事とのバランスに反映されます。

疑問が生じます-なぜこのすべての情報をデータベースから取り出し、処理し、書き戻す必要があるのですか？ そのような必要はまったくありません ユーザーは自動支払い処理から完全に除外されます。 したがって、これはすべて、データ処理レベルで決定することができ、データベースサーバーは完全に関与します。

しかし、結局のところ、オブジェクト手法でビジネスロジックを分離するために使用したという事実は、私たちにとってはまったく役に立ちませんでした。 キューからの支払い注文を単に保持するストアドプロシージャが1つだけ必要でした。 はい、この場合、ビジネスロジックはストアドプロシージャに入ります。

クライアント/サーバーアーキテクチャに代わるものはありません-これは、ロジックがクライアントにあった場合、サーバーに移行する必要があり、クライアントに複製が残る方法の例です。ただし、一般的なビジネスロジックをストアドプロシージャでサーバーに転送し、クライアントでのみサービスを残す方が論理的ですユーザーインターフェース。

3層アーキテクチャでは、ビジネスロジックがサーバー（中間層）上にあると想定し、このタスクのためにクライアントをバイパスします。 しかし、最初に、追加のリンクを導入し、次に、このタスクで再びクライアントの役割を実行します-データベースからデータをポンプし、処理して、書き戻します。 そして、これはすべて、オブジェクトロジックでビジネスロジックを処理するのを便利にするだけです。 価格は素晴らしいですか？

2番目のケースは、もうすぐでした。 光熱費のシステムを実装する必要がありました。 実際、これは支払いシステムの別のアドオンです。 公共料金の支払いには、サービスの説明、検針、借金、支払い方法、頻度などの技術情報など、特定の追加情報が含まれます。 そして、その後、共同注文に基づいて、実際の支払い注文が作成されます。 ここでの銀行の機能は、サービスの支払いのためにさまざまなチャネルからの支払いを蓄積し、1つの統合された支払いを使用してサービスプロバイダーのアカウントに振替を行うことです。 したがって、支払い注文が添付された公共料金の注文はパッケージに収集されます。 繰り返しになりますが、特定のビジネスロジックに基づく注文はパッケージに分類され、この場合もユーザーインターフェイスはありません。 パッケージは、特定の基準に従って自動的に生成されます。 そして、世界はユーザーの介入なしに回転します。

ここで、ビジネスロジックはデータベースで有効であると教えられました。共同注文に基づいて実際の支払いを生成するロジックは、ストアドプロシージャを使用して実行されました。 さらに、インターフェイスを介してユーティリティ注文を作成するとき、および銀行システムに関連する外部（会計など）プログラムのAPIとして、またインターネットバンクを介してユーティリティ注文を受信するときに使用されました。 これは、ビジネスロジックがストアドプロシージャではなく、たとえばC＃のオブジェクトにある場合に可能ですか？ はい、可能ですが、完全に冗長な中間リンクを導入して、データベースへのデータの取得/書き込み方法を複製します。

しかし、パッケージにたどり着くと、ビジネスロジックにより、特定の標識の支払いを選択し、同じ標識（パッケージに属している、ステータス、ユーザーへのテキスト説明など）をすぐに大きな支払いのセットに置き、関数を使用してパッケージの合計金額と支払い数を計算する必要がありますSUM（）、COUNT（）...そして、これらすべてがオブジェクト指向の方法論で実装され、SQLを使用しない場合、私は非常に驚くでしょう。 そして、結論として、パッケージが形成された後、統合された支払いを生成する必要があり、SQLからそれを形成することはできません-これは、ビジネスロジックがデータベースにないという事実の唯一の利点ですか？

これらの2つの例は、データベースストアドプロシージャでビジネスロジックを見つけることが正当化される以上のものであり、場合によっては必要であることを理解するのに十分だと思います。

そして実際には、実際には2種類のビジネスロジックがあります。 1つのビジネスロジックはユーザーとの対話方法を定義し、もう1つのビジネスロジックはバッチ処理に関連しています。 最初のケースでは、クライアントまたは中間リンク上のオブジェクト言語でビジネスロジックを管理するのが非常に便利です。次に、データの自動バッチ処理では、最初にデータベースからロードせずに、セカンダリデータではなくプライマリデータで作業するのが理にかなっています書き戻すことなく。

別の極端な視点

議論の対象となっている記事の著者が、データベースにビジネスロジックを含めるべきではないという極端な観点を1つ（合理的には十分ではないが）表現した場合。 また、すべてのビジネスロジックをデータベースに含めることができる別の極端な視点を表現することもできます。 同時に失うのは、ビジネスロジックを操作するためのオブジェクト手法が不足していることだけです。

どのような場合にこれを正当化できますか？

少し前に、ブラウザゲームを作成するためのスタートアップについて書きました。 そして、そのようなアプローチが実際に使用されているのは、データベース内のすべてのビジネスロジックです。 何が原因ですか？

Web開発はまだ非常に具体的です-クライアントはブラウザーであり、常に異なるスクリプト言語（JavaScript）によって制御されます。 サーバーのタスクは、クライアント用のHTMLページを形成することです。 この点で、オブジェクト指向言語を使用してクライアントを管理することはできなくなりました（JavaScriptがオブジェクト言語と見なされている場合を除き、完全ではありません）。 したがって、クライアントからデータベースの外部にビジネスモデルを作成するために、データベースからデータをプルする主なインセンティブはなくなります。

サーバー上でほぼ同じこと。 もちろん、ここでは、ASP.NETを使用する場合など、オブジェクトの方法論を奪われていません。 ただし、サーバーのタスクはHTMLの形成-ページです。 むしろ、単純な選択要求を使用して、ルールとしてストアドプロシージャによって取得されたデータをHTMLページに入力します。 はい、もちろん、ボタンを押したり、チェックボックスなどをクリックしたりすると、まだ反応があります。 しかし、ユーザーとの対話のかなり複雑なロジックが実装されているフォームを備えたオフィスアプリケーションとは異なり、Webページは非常に単純化されています。 通常、反応は他のデータを含む別のHTMLページの形成に帰着します。

要するに、Webアプリケーションには「舞台裏」で実行されるタスクがあります。 たとえば、私が実装するブラウザーゲーム（RPG要素を備えた経済戦略）では、これらは、製品を作成するための生産プロセスの確認、市場特性（購入価格）の計算、購入、ギルド選挙、長期配達などのタスクです。 .p。 それらはすべてゲーム内で一定の周期で実行され、ビジネスロジック全体の60〜80％を占め、すべてプレイヤーの「舞台裏」で発生します。 そして、これらのタスクの実装のために、プライマリデータを引き出してオブジェクトモデルの形式で提示する必要があり、処理後にこのデータを書き戻す必要がある場合は奇妙です。 データ選択（選択クエリ）は、ストアドプロシージャによって何らかの形で実装されます。

残るのは、ボタンを押したときの反応、およびインターフェイスとのその他の関係だけです。 繰り返しになりますが、JavaScriptaの場合、すべてはデータの塊を取得することであり、ビジネスロジックとはほとんど言えないクライアント側アルゴリズムの作成は、インターフェイスマッピングロジックです。 また、オブジェクトモデルのHTMLページを介してユーザーとのインタラクティブな作業を提供するビジネスロジックを残すために、このインタラクティブ性の単純さのために、これは利点を提供するよりも有害である可能性が高くなります。

したがって、Webアプリケーションの場合、ほとんどすべてのビジネスロジックがデータベースにあることがわかります。 これにより、Webサーバーの動作に関係なく、ゲームのコアがデータベース内で独立して動作できるようになります。 ストアドプロシージャをAPIとして参照して、他のクライアントを作成できます。 マイナスは1つだけです-オブジェクト言語なしでビジネスロジックを実装することはあまり便利ではありませんが、多くの場合、複数のオブジェクトを操作するロジックであり、これらもデータベース内の多くのエンティティに対するグループ操作であるため、それほど単純ではありません。

他にアーキテクチャ上の欠点はありません。データベースにビジネスロジックが存在することです。