データベースから移動するときにビジネスロジックを移動する場所

Question

私はストアドプロシージャ内のすべてのビジネスロジックを持つCRUD重いASP.NETアプリケーションを使用しています。

たとえば、〜500行の長さのUPDATEストアドプロシージャがあり、多数の条件付きロジックを含み、複数のテーブル& UDFを参照します。 procは更新されたフィールド名と新しい値を取り込み、宣言された変数の束を設定し、一連の検証を行い、更新を行うための動的SQL文を作成します。サイズが一度合う。それは大きくて混乱します。

ビジネスロジックを.NET側に移行して、ソース管理下での管理/更新、テスト、および配置を容易にしたいと考えています。

私の質問は次のとおりです。このビジネスロジックはどこに行くべきですか？

「Factory」というプロパティを持つPurchaseOrderオブジェクトがあります。工場が変更された場合、割り当てられた新しい工場がPurchaseOrder上にあること、価格が設定されていること、その工場に基づいて要求された最小数量があることなどを確認する必要があります。データベース。

PurchaseOrderオブジェクトのFactoryセッターは、 'isFactoryValid'メソッド/プロパティを使用してデータ検証を行い、汎用データアクセスオブジェクトへの複数の呼び出しを行い、それがあれば更新を行う必要がありますか？

またはPurchaseOrder関連のデータアクセスだけを処理するPurchaseOrder/Database 'proxy'オブジェクトを作成しますか？この場合、PurchaseOrderのセッターによって呼び出されたプロキシに「isFactoryValid」メソッドがあり、プロキシの更新メソッドが呼び出されますか？

これらの余分なコールのすべてでデータベースへのトラフィックを増やすことを心配する必要はありません。それを行うには

Answer 1

広くDBのうち、永続ロジックを実装するために使用される2つの主なパターンがあります。

• ActiveRecord Patternは - 永続ロジックは、ドメインオブジェクトです。
• Repository Pattern - 別のオブジェクトまたはレイヤーがデータアクセスを処理します。あなたの「プロキシ」コンセプトはこれを解決します。

両方のオブジェクトとのトリックは、データベースへの旅行を作る際に知り、いないときに知っです。例えば、はとなります。DBとドメイン層の間で行われる冗長な検証です。たとえば、DB呼び出しを行う前であっても、ヌル値ではないと評価し、文字列を長さに切り捨てるなどです。 dbに保存を呼び出す必要があります。

遅延ロードやトランザクションなどのパフォーマンスを向上させたり、データベースの移動を最小限に抑えるためのさまざまな方法があります。

Answer 2

一つの方法： あなたは層のためのインタフェースと.NETのデータ層（1または複数のデータクラスを）持っている...あなたが使用してビジネス・ロジックを実行し、ビジネス層を持っていますインタフェース。 http://en.wikipedia.org/wiki/Multitier_architecture

Answer 3

また、ビジネスロジックを再利用可能なWebサービスのチャンクに変換することもできます。 WCFは優れたツーリングサポートを提供します。

Answer 4

ドメインドリブンデザイン（DDD）を参照してください。これはあなたの質問の多くに答えます。データアクセスのためのリポジトリと検証のための仕様について述べています。良いORMも役に立ちます。この本はまた素晴らしいです：これは、あなたが作成したオブジェクトモデルに依存し、あなたが聞かせてきたどのようにあなたの呼び出し側が工場発注書を処理するために新しい工場になるかを決定

alt text http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7.jpg

Answer 5

。

たとえば、発信者に選択可能なファクトリのリストを提供する場合、既存のPurchaseOrderに関連付けられた製品をサポートするファクトリにのみフィルタを設定できます（既存の注文を編集したと仮定しています） ）。ファクトリが注文を処理できることをPurchaseOrderで確認するには、PurchaseOrderでSetterにFactoryのメソッド（CanProcessOrderFor（製品、数量）のようなもの）を呼び出します。

ファクトリとPurchaseOrderのリストを取得するためにデータベースクエリを実行しなければならないと仮定します。ファクトリオブジェクトのクエリで、サポートされている製品と現在の数量（または最小限の注文 - あなたのロジックが必要なもの）の一覧が返されます。

NHibernateのような良いORMは、これが一般的なシナリオであれば、ラウンドトリップを最小限に抑えるためにこれらの結果の一部をキャッシュすることができます。