5

この投稿(ビジネス ロジック データベースまたはアプリケーション レイヤー) を読んだ後でも、「データベース内のビジネス ロジック」のトピックと戦う十分な理由がありません。

私の現在の仕事では、多くのデータベース トランザクションが (実際には) あり、すべてのくだらないコードは維持するのが難しく、ストアド プロシージャに多くの重複があるため、テーブルの値を少し変更したい場合は、これらの手順をすべて見つけて、必要なものに変更する必要があります。テーブルのデザインを少し変更する必要がある場合も同様です。

現在のすべての開発者は SQL をよく知っていますが、エンジンとしてのデータベースの専門家ではありません (8 人の開発者)。

現在、コア全体を新しいバージョンに移行する予定です (データベース設計を含む)。そして、次の例が必要です。

  • データベースのビジネス ロジックが時々 EVIL になるのはなぜですか?
  • データベースでのビジネス ロジックは、いつ、どのくらいの頻度で使用するのが適切ですか?
  • アプリケーション層のビジネス ロジックがエンタープライズ アプリケーションに適している理由。?

アプリケーション言語: Java
データベース: Oracle11g
アプリケーションにはサービスがあり、HTTP ページおよび Web サービスとして提供されます。

4

8 に答える 8

4

これらのAskTomスレッドを読んだことがありますか？

彼らは良い読書であり、トム・カイトからの素晴らしい知恵に満ちています。唯一の問題は、彼らがあなたが望んでいる答えをサポートしていないことです-彼らは反対の見方をサポートしています！

于 2011-03-02T16:16:51.847 に答える
4

データ層のビジネスロジックは、一般的なものに固執しようとするいくつかの理由から、通常は悪と見なされます。

  1. ユニットテストをきれいに行うことはできません：

    単体テストの一般的な考え方の1つは、問題があることを伝えるだけでなく、問題がどこにあるかを伝えることです。BLがデータレイヤーにあり、BLテストが機能していない場合、問題がロジックにあるのかデータにあるのかを判断できません。これにより、デバッグ時間が長くなります。

  2. レイヤー全体をスタブしてモックする：

    層状構造を持つことの主な利点の1つは、層全体をスタブ化することです。したがって、スタブDAOレイヤーを使用している間、ロジックを個別に（おそらく別のチームによって開発されて）進化させることができるため、データをどこからどのように取得するかについて心配する必要はありません。これにより、ドメインモデルがまだ完成していることを心配することなく、ロジックを自由に開発できます。

  3. ティア：

    レイヤーがきれいに分離されている場合は、別々の物理インスタンス（たとえば、異なるサーバー）でレイヤーを操作する方がはるかに簡単です。したがって、たとえば、データレイヤーをスケーリングするだけの複数のサーバーを使用できます（これは珍しいことではありません）。明らかに、ロジックがそこにある場合、それははるかに困難になります（可能であれば）。

于 2011-03-02T16:25:02.147 に答える
4

くだらないコードは確かに保守が困難です。それがくだらないコードの性質です - それがどこにあるかではありません。「フロントエンドのくだらないコード」ソリューションに移行することは、実際には解決策ではありません。

また、データベース構造の変更がフロント エンドでコーディングされたビジネス ロジックに影響を与えないと思われる場合は... うーん、ロジックによって指示が異なります。

フロントエンドでうまく処理できるものもあれば、バックエンドでうまく処理できるものもあると思います。また、ビジネス オブジェクト レベルで動作する適切な PL/SQL API 設計は、構造変更の問題を他のレイヤーから分離することで軽減できると思います。

しかし、他の DB をサポートする考えがある場合、すべての DB が同じ構造をサポートしているわけではないため、これも問題のある考えです。

ビジネス ロジックがどこに属しているかについては、アプリケーションに完全に依存する可能性があり、実際、パフォーマンス上の理由から、いくつかの側面を複数のレイヤーに配置すると有利な場合があります。もちろん、これはメンテナンスの問題を引き起こす可能性がありますが、これはすべて、プロジェクトまたは製品を提供するために必要なトレードオフの一部になります.

しかし、確かに厳密で普遍的な答えは 1 つではありません。

于 2011-03-02T16:28:14.260 に答える
2

もしそうなら、それは悪い設計選択かもしれません (EVIL ではありません)。

  1. 複数のデータベース ベンダーをサポートする必要がある
  2. 異なるデータベース バージョンをサポートする必要がある
  3. 異なるデータベース エディションをサポートする必要がある
  4. 非データベース層にロジックを追加すると、データベース サーバーの CPU 負荷が軽減され、関連するライセンス コストが削減されることを示すことができます。そのロジックを非データベース層に追加すると、データベース リクエスト、ネットワーク トラフィック、使用中のデータベース セッション、データ キャッシュの重複などが増える場合、実際にはデータベース層に負荷がかかり、何も保存されていないことがわかります。 .
  5. 既存のスキルセットの誤用。スタッフ全員が Java のスキルを持っている場合、PL/SQL (または Ruby または .Net) で新しいアプリケーションを開発してもほとんど意味がありません。同様に、スタッフが PL/SQL のスキルを持っている場合、Java で再構築するには費用がかかります。
  6. ツールの不足または費用。Oracle 用のテスト フレームワークはありますが、商用のもの (Quest など) はオープン ソースのものよりも優れています。
于 2011-03-02T22:39:14.333 に答える
2

- データベースのビジネス ロジックが時々 EVIL になるのはなぜですか?

  1. DB を使用している場合、ロギングを実装する方法は? DBにログを記録しているとは言わないでください。:)
  2. スケールアップしにくい。
  3. 通常、データベース スクリプトは読みにくいものです。
  4. テストとモックが難しくなります。
  5. データベースを変更する必要がある場合はどうなりますか? たとえば、会社が Oracle ライセンスを購入できなくなったため、別のデータベースに変更する必要があるとします。移行は大きな問題になります。

- データベース内のビジネス ロジックは、いつ、どのくらいの頻度で使用することをお勧めしますか?

できるだけ最小限に。私は通常、アプリケーションへの実装がデータベースのパフォーマンスに重大な影響を与える場合にのみ使用しました。このような理由から、PL/SQL で実行することをお勧めします。

-アプリケーション層のビジネス ロジックがエンタープライズ アプリケーションに適している理由。?

答えは最初の答えと同じです。

于 2011-03-02T17:36:54.040 に答える
1

データベースのビジネスロジックが時々EVILになるのはなぜですか？各ベンダーの更新ごとに作業する必要があります。サポートをあるベンダーから別のベンダーに移動する場合は問題が発生します。投稿の1つに記載されているように高価です。

データベースのビジネスロジックはいつどのくらい良い習慣ですか？ビジネスロジックに関係しないストアドプロシージャを介して外部キーまたは関連する行を更新または削除するためのロジックは問題ないはずです。

アプリケーション層のビジネスロジックがエンタープライズアプリケーションに適している理由。？まず、保守が簡単なアプリケーションレイヤーは、フレームワークを活用して、車輪の再発明を行わないようにするために、多大な時間と費用を節約できます。アプリケーション層に使用されるスレッド化または言語固有の能力を活用します。

于 2011-03-02T16:37:31.480 に答える
1

1つには、別のデータベースブランドに移行できるようにする場合は、ストアドプロシージャにビジネスロジックを含めるべきではありません。

また、複雑なドメインの場合、ドメインのモデリングは、DB側よりも、オブジェクト指向モデルを使用したJava側の方がはるかに自然です。OOは、抽象化とそれらの間の関係を表現するのに適しています。

この主題に関する標準的な本は、ドメイン駆動設計です。

DB側にとどまる理由はパフォーマンスかもしれません。大量のビジネスデータがある場合、アプリケーションでデータを取得して操作するのに十分な効率が得られない可能性があります。これは特にバッチ処理に当てはまります。

于 2011-03-02T16:16:12.913 に答える
1

データベースのビジネスロジックの問題は

  • 拡張するには費用がかかります。あなたはオラクルを使用しているので、オラクルを実行する別の 16 コア ボックスを追加するのにどれだけの費用がかかるかがわかります。おそらく 75 万ドル程度です。
  • DB のベンダーに縛られています (技術的にも、コードを移行することはできません)。

メリットは

  • ワンストップショップ: すべての DB クライアントが同じロジックを実行します。複数のインターフェースを使用する場合は、すべてが同じロジックを使用できます。

私は、DB にすべてのロジックを持っている保険会社で働いていました。このような大きなアーキテクチャ上の決定を下すには考慮すべき点がたくさんあるため、あなたの質問に対する答えは非常に抽象的なものになると思います。

于 2011-03-02T16:23:26.293 に答える