3

アプリケーションのビジネス ルールをどこに配置するかを決定しようとして、少し混乱しました。

asp.net の従来の Web フォーム (mvc ではない) を使用して Web アプリケーションを開発しています。その上に、データベースに書き込むためのリポジトリ パターンがあるクラス ライブラリがあります。リポジトリ パターンに「ビジネス レイヤー」があり、テーブルに影響を与えるストアド プロシージャも作成しています。

Mandatory field validation rules など、どこに配置すればよいですか?

他の例は、外貨を米ドルに変換することです（私は為替レート表を持っていますが、現在はsprocsで行っています）。

ルールの sprocs から離れて、私のリポジトリ ビジネス レイヤーですべてを構築することをお勧めしますか? またはどのような場合に、sprocs 内でルールと検証を構築することをお勧めしますか?

4

2 に答える 2

4

この回答は、複数のデータ ソースを使用しないか、十分に単体テストされたビジネス レイヤーを持たない小さなアプリケーションを開発し、サービス レイヤー (キャッシュなど) を追加する予定がない場合に適しています。コメントで反対派を参照してください。

よろしければ、次のことをお勧めします。

  1. リポジトリ パターンを完全に削除します。複数のデータベースをサポートする必要は本当にありますか?

  2. データベースではなく、ビジネス ロジックをビジネス レイヤーに保持します。利点は、ルールの局所性にあります。すべてのドメインは、一連の条件、ルール、戦略などとして表現され、すべて 1 か所に配置されています。それらをデータベースに保存することを選択した場合、コードを維持するときにさらに頭痛の種になります。

  3. ビジネス層にあるコードを単体テストするのは簡単です。SPの単体テストが可能かどうかはわかりません。

  4. SP とリポジトリ パターンはうまく連携しません。

通貨レートは刻々と変化します。このためには、呼び出して正確な値を取得できる信頼できる Web サービスを使用する必要があります。

概要：

  • SPから離れる
  • リポジトリ パターンに近づかない
  • リポジトリ パターンの抽象化の代わりに ORM を直接使用する
  • 永続性とビジネス ルールを混在させない
  • ビジネス ルールを別の (再利用可能な) アセンブリに分割する
于 2012-07-23T23:39:19.027 に答える
1

  • あなたのリポジトリにはビジネスレイヤーがあるはずがありません。唯一の目的は、データベースの抽象化として機能することです。その中で、アプリケーション データの保存/取得方法を管理します。

  • 頻繁に変更されないデータベース操作には SP を使用します。ビジネス ロジックを SP 内に配置しないでください。ビジネス ロジックは、時間の経過とともに変化する傾向があります。

  • ビジネス オブジェクトが存在するドメイン層を作成できます。ビジネス オブジェクトは、独自の検証ロジックをカプセル化する必要があります。

  • ビジネス/ドメイン オブジェクト以外に、実際にビジネス オブジェクトを使用してデータに対してビジネス ロジックを検証するユーティリティ クラス (CurrencyManager や CurrencyHelper など) がある場合があります。

  • 最後に、ドメインをあらゆる種類のプレゼンテーション/ビュー レイヤー参照から解放するようにしてください。ビュー レイヤーでビジネス検証ルールを適用したり、ドメイン レイヤーで検証ロジックを表示したりしないでください。

-それがいくつかの光を当てることを願っています.

于 2012-07-24T04:04:56.600 に答える