DataAccess / DataLayer プロジェクトを作成し、そこに EF をカプセル化して、実際に EF を使用していることを MVC プロジェクトが認識しないようにしたいと考えています。将来的に NHibernate を使用することに決め、Visual Studio によって作成されたすぐに使用できる MVC プロジェクトが EF リファレンス/DLL を Web プロジェクトに追加します。もちろん、EF参照が必要なため、MVCからDbContextにアクセスすることはできません。
その結果、EF が必要なため、Code First のデータ注釈を使用できなくなります。
リポジトリを作成する価値はありますか、それとも「シンプル」に保ち、MVC プロジェクトに EF 参照を追加する必要がありますか?
コンテキスト/データベースを使用するすべてのプロジェクト、テスト、およびクライアントに EF への参照を追加する必要があることは、私には意味がありません。
ありがとう
作成しようとしているのは、典型的なレイヤーパターンです。上部にはプレゼンテーション層があり、中央にはビジネス層があり、下部（または最後の層）にはDAL層があります。
レイヤーをどのように設計するかは完全に意見とニーズに依存しますが、上記で説明した方法では、3つの異なるプロジェクトが必要です。MVCプロジェクト、ロジックプロジェクト、およびDALプロジェクト。DALプロジェクトには、EF参照とリポジトリオブジェクトが含まれます。次に、DbContext / ObjectContextアイテムをPOCOに変換して、ビジネスレイヤーで使用するかどうかはユーザー次第です。ビジネスレイヤーはEFについて知っていますが（EFオブジェクトの受け渡し方法によって異なります）、ビジネスレイヤーは独自のオブジェクト（DALレイヤーオブジェクトからのマッピング）をMVCに渡します。つまり、EFをMVCレイヤーから完全に切り離します。 。
このタイプのパターンを使用する場合は、さらに一歩進んで、ブートストラップされたコンテナー（Unity Frameworkを使用した横断的プロジェクトなど）を使用した依存性注入を含める必要があります。
Microsoft Pattern＆Practices、http：//msdn.microsoft.com/en-us/library/ff650706を参照してください（第25章は階層化の良い例です）。
HTH
私は、DAL を 1 つの DataAccess テクノロジまたは特定のデータベースから分離するという正確な目的のために、ほぼすべてのプロジェクトにリポジトリ システムを実装することにしました。