ViewModel パターンと Entity Framework の Repository パターンを使用する MVC3 アプリがあるとします。
それぞれが複数のエンティティで構成される作成ビューと更新ビューがある場合、データを保存するためのベスト プラクティスは何ですか?
各エンティティのデータをそれぞれのリポジトリに保存する抽象化されたサービス レイヤーを使用して日付を保存する必要がありますか、それともストアド プロシージャを使用してリポジトリにデータを保存する必要がありますか?
私はどんな提案や推奨事項にもオープンです。
前もって感謝します！
これは、DDD/CQRS アプローチが最も有効なケースの 1 つです。簡単に言えば、特定の動作 (集約) をモデル化するいくつかのビジネス オブジェクトがあります。chrage には、明示的な境界を持つ Aggregate Root (AR) と呼ばれるオブジェクトが 1 つあります。保存する場合は、AR 全体をリポジトリに送信し、すべてをトランザクションとして保存します。
ワークフロー
ユーザーは、ビュー モデルを介してデータを送信します。次に、コントローラーはリポジトリから AR を取得するか、新しい場合は作成します。入力データは、通常は AR メソッドを介して AR にマップされます。データまたはその結果がいくつかのビジネス ルールに違反していることを AR が検出した場合、AR は例外をスローする必要があります (基本的な検証は asp.net mvc によって既に自動的に実行されていると想定しています)。
すべてが問題なければ、コントローラーは AR をリポジトリーに送信し、AR を EF エンティティーにマップし、それをすべてトランザクション内で保存します。
これは簡単に言えば、私が行う方法です。もちろん、実際には少し異なる方法で実装しますが、概念は同じです。重要な部分は、関係を処理する方法を知っている AR にすべてのデータを送信することです。
重要なポイント
AR がリポジトリに到達した後でのみ EF について言及したことに注意してください。つまり、AR は EF エンティティとは関係なく、完全に分離され、実際のビジネス モデルを提供します。モデルが更新された後でのみ、EF とレポ内のみが考慮されます (EF はレポの実装の詳細であるため)。リポジトリは、関連する EF エンティティに AR データを転送 (基本的にマップ) し、エンティティを保存するだけです。
ビジネス (ドメイン) モデルと永続化モデル (EF エンティティ) を明確に区別することが重要です。EF を使用してビジネス ルールを処理しないでください。データベースからデータを監視/取得するためだけに使用してください。EF は、RDBMS アクセスのみを抽象化し、仮想 OOP データベースとして使用するように作成されました。
ViewModel パターンについて言及しました。そのようなパターンについては聞いたことがありません。MVC を使用するたびに、既に ViewModel を使用しています。繰り返しますが、秘訣は EF エンティティを ViewModel として使用しないことです。ビューに適合する「ダム」ビュー モデルを使用します。VM パーツを直接返す特殊なクエリ リポジトリを介して VM にデータを入力します。リポジトリは EF エンティティをクエリし、単純な DTO である VM ビットを返します。これは、データを表示するときに検証やビジネス ルールが必要ないためです。
レイヤー、特に各レイヤーのモデルを分離しておくことは良い習慣だと思います。ものを更新するには、複雑なビジネス オブジェクト (ドメイン モデル) を使用します。これは難しい作業を行い、その状態を (リポジトリ経由で) EF に転送するだけです。内容を読み取るには、EF にクエリを実行し、VM に適した単純な DTO を返します。
これが CQRS の本当の目的です。1 つのモデルに異なる責任 (書き込みと読み取り) を当てはめようとしないでください。