2

ストアド プロシージャにすべてのビジネス ロジックを備えた CRUD を多用する ASP.NET アプリケーションがあります。

例として、最大 500 行の長さで、複数のテーブルと UDF を参照する大量の条件付きロジックを含む UPDATE ストアド プロシージャがあります。proc は、更新されるフィールド名と新しい値を受け取り、一連の宣言された変数を設定し、一連の検証を行い、更新を行う動的 SQL ステートメントを作成します。一度サイズがすべてに収まります。大きくて紛らわしいです。

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

私の質問はこれです: このビジネス ロジックはどこに行くべきですか?

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

PurchaseOrder オブジェクトの Factory セッターに、汎用データ アクセス オブジェクトへの複数の呼び出しを行う「isFactoryValid」メソッド/プロパティを介してデータ検証を行う責任を持たせ、そうであれば更新を行う必要がありますか?

それとも、PurchaseOrder 関連のデータ アクセスのみを処理する、PurchaseOrder/Database 'proxy' オブジェクトを作成しますか。この場合、PurchaseOrder の setter によって呼び出される「isFactoryValid」メソッドをプロキシに配置し、次にプロキシの update メソッドを呼び出しますか?

これらすべての余分な呼び出しでデータベースへのトラフィックが増加することを心配する必要があるかどうかを判断するにはどうすればよいですか?

4

5 に答える 5

2

それを行う1つの方法： .net（1つまたは複数のデータクラス）にデータレイヤーがあり、レイヤーのインターフェースがあります...次に、インターフェースを使用してビジネスロジックを実行するビジネスレイヤーがあります。http://en.wikipedia.org/wiki/Multitier_architecture

于 2009-04-22T00:37:11.063 に答える
1

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

  • ActiveRecord パターン- 永続化ロジックはドメイン オブジェクトにあります。
  • リポジトリ パターン- 別のオブジェクトまたはレイヤーがデータ アクセスを処理します。「プロキシ」の概念がこれに対応します。

両方のオブジェクトの秘訣は、データベースにアクセスするタイミングと、そうでないタイミングを知ることです。たとえば、DB とドメイン層の間で冗長な検証が行われます。たとえば、DB 呼び出しを行う前であっても、null 値ではないことを評価したり、文字列を長さに合わせて切り捨てたりする必要があります。これらのチェックが完了した後でのみ、データベース内の Save への呼び出しが行われる必要があります。

遅延読み込みやトランザクションなど、パフォーマンスを向上させたり、データベースのトリップを最小限に抑えるために利用できるさまざまな戦略もあります。

于 2009-04-22T00:43:11.283 に答える
0

これは、作成したオブジェクトモデルと、PurchaseOrderを処理する新しいファクトリとなるファクトリを呼び出し元にどのように決定させるかによって異なります。

たとえば、発信者に選択できるファクトリのリストを提供する場合、既存のPurchaseOrderに関連付けられた製品をサポートするファクトリのみにリストをフィルタリングできます（既存のオーダーを編集したと想定しています）。Factoryが注文を処理できることをPurchaseOrderに検証させたい場合は、PurchaseOrderのセッターにFactoryのメソッド（CanProcessOrderFor（product、quantity）など）を呼び出させます。

工場のリストとPurchaseOrderを取得するには、すでにデータベースクエリを実行する必要があると思います。Factoryオブジェクトのクエリで、サポートされている製品と現在の数量（または最小順序-ロジックが必要なもの）のリストを返すようにします。

NHibernateのような優れたORMを使用すると、これらの結果の一部をキャッシュして、これが一般的なシナリオである場合にラウンドトリップを最小限に抑えることができます。

于 2009-04-23T03:17:25.037 に答える
0

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

于 2009-04-22T00:39:57.593 に答える
0

ドメイン駆動設計 (DDD) を調べると、かなりの数の質問に答えることができます。データ アクセス用のリポジトリと検証用の仕様について説明しています。優れた ORM も役立ちます。この本も素晴らしいです：

代替テキスト http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7.jpg

于 2009-04-22T00:49:05.510 に答える