現在、私はプロジェクトを MVC 2 から MVC 4 に更新しており、カスタム ORM/データ アクセス「レイヤー」を EF 4.3.1 に交換しようとしています (5 にアップグレードするときは、それがリリースされます)。コントローラーは、DB クエリとストアド プロシージャのラッパーである別のファイルの関数を使用します。
だから、私の質問はこれです: ラッパー関数でこのファイルを削除し、EF を直接使用してコントローラーからデータを取得する必要がありますか、それとも各関数の内容を削除して EF コードに置き換える必要がありますか?
あなたが私に与えることができる他のデザインのヒントはありますか？
ありがとう ！
リポジトリ パターン (まさにあなたが行っていること) を使用すると、たとえば NHibernate を使用するコードや MySql に接続するコードでその単一のファイルを交換できるため、将来的により柔軟になります。このようにして、コードは EF と密結合されず、必要に応じて簡単に EF から離れることができます。
そうは言っても、明らかにリポジトリ パターンに関連するコーディング オーバーヘッドがいくらかあります。コードを EF と緊密に結合することに関心がない場合は、確実に後者のルートに進むことができます。
これは単に選択の問題だと思いますが、どちらも特定のシナリオでは有効なようです。そうは言っても、データベースへのアクセスを簡素化し、共通の機能を提供し、必要に応じて他のデータ プロバイダー (Hibernate など) をラップするクラスに簡単に交換できるクラスを使用する大規模なプロジェクトでは、そう思います。
さらに、追加のデータ プロバイダーを追加する場合があり (たとえば、他のサイトの API を使用する)、これらのデータ プロバイダーをコントローラーに直接含めると、非常に読みにくいコードが生成されます。
このアプローチはコントローラーも大幅に簡素化します。最初は大したことではないように思えるかもしれませんが、重要な機能を備えたコントローラーが追加されるにつれて、付加価値が明らかになります。