重複の可能性:
MVC でデータベースとビジネス ロジックを記述する場所は?
私はMVC3パターンを始めたばかりです。MVC3 でデータ アクセスを行うにはどうすればよいですか? 'MODEL' をデータ アクセス レイヤーとして作成しますか? それとも、別の 'DAL' レイヤーを追加して 'MODEL' レイヤーから呼び出しますか?
重複の可能性:
MVC でデータベースとビジネス ロジックを記述する場所は?
私はMVC3パターンを始めたばかりです。MVC3 でデータ アクセスを行うにはどうすればよいですか? 'MODEL' をデータ アクセス レイヤーとして作成しますか? それとも、別の 'DAL' レイヤーを追加して 'MODEL' レイヤーから呼び出しますか?
モデルは、将来的に DAL 戦略を変更できるようにするデータ アクセス要素から独立している必要があります。
DAL からモデルをフィードする必要がありますが、モデルはそれがどのように構築されているかを認識してはならず、データベース固有のコードを含むべきではありません。
私が提案するアプローチを取る場合は、AutoMapper を見てください。これは、DAL とモデル クラスの間でデータをマッピングするための非常に便利なツールです。
前回の MVC3 プロジェクトで作業していたとき、さまざまなサンプル (GeekDinner など) から理解したのは、Entity Framework がデータ アクセス層として機能するということでした。
モデルは、直接マップされたデータ アクセス オブジェクトにすることができますが、必ずしもそうである必要はありません。それらは、プロジェクトの要件と寿命に応じて、常により良いオプションになるバックエンド DAL へのプロキシになることもできます。
大規模なプロジェクトでこれを処理する方法Project.Entities
は、Entity Framework データ モデルを含む別の名前空間を呼び出すことです。MyProject.Models
には、エンティティをデータのバッキング ストアとして使用するモデルが含まれ、そのデータを操作するための一般的なメソッド (必要な場合) が提供されます。これは最善の方法ではないかもしれませんが、最も柔軟性が高く、データ モデルをバッキング ストアから分離することに固執するため、より抽象化が可能になります。たとえば、基になるデータ レイヤーをメモリ内ストレージ、Entity Framework 以外の別の DAL などにいつでも切り替えることができます。
小規模/一時的/テスト プロジェクトの場合、私の Entity Framework データ モデルはそのままでProject.Models
直接使用できます。より高速で、あまり考える必要がないからです。
いいえ、モデルはデータ アクセスではありません。モデルはデータを保持するためのクラスの集まりであり、通常、割り当てられた値が許可されていることを確認する以外のコードは含まれていません。
コントローラーからデータにアクセスします。どちらの方法でそれを行うかは完全にあなた次第であり、MVC は関係ありません。
Model はビュー モデルであり、ドメイン モデルではありません。
DAL アクティビティを実行したい場合は、コントローラーに挿入できるリポジトリ/サービスにラップする傾向があります。
これにより、コントローラーが肥大化するのを防ぎ、コントローラーの単体テスト用に DAL レイヤーをモックすることもできます。