エンティティフレームワークのないリポジトリパターン？
エンティティフレームワークを使用せずにリポジトリパターンを実装することは可能ですか？
私は小規模な（今のところ）ASP.NET MVCソリューションで3人の小さな開発チームに取り組んでいます。私はマネージャーに、ビジネスロジックとコントローラーの間に抽象化のレイヤーが必要だと思うと言いました。現在、私たちのコントローラーには、多くのビジネスロジックやその他の機能が含まれています。
私は過去に最後の位置でリポジトリパターンを使用しましたが、そこで実装していません。そして、私はパターンを100％「包み込み」、自分でそれを実装する方法を知っているとは言えません。このパターンには非常に多くのチュートリアルがあり、たとえわずかな違いであっても、通常はすべて異なるように見えます。
私のもう1つの懸念は、私のチームの他のプログラマー（上級開発者）が、今はEFに切り替える必要はないと言っていることです。私たちのプロジェクトはまだ小規模で、移行する時間がないためだと思います。私はこれを尊重し、理解しているので、EFなしでこのパターンを引き続き使用できるかどうか疑問に思っています。
もしそうなら、誰かが役に立つチュートリアル、例、またはリファレンスを持っていますか？
そうでない場合、次に何をするべきですか？手ぶらで現れたくない。私は（実際の）オブジェクトを、機能を格納および提供するクラスとして表すことができます。そうすれば、コントローラーで実行されるロジックや機能が減ることが期待されます。
読んでくれてありがとう。
リポジトリパターンなどのデザインパターンは特定のテクノロジーに依存しないため、質問への明確な答えは「はい、もちろんできます」です。最終的に任意のストレージテクノロジーに裏打ちされたリポジトリを作成できます。つまり、Repositoryパターンは、データアクセスコードを構造化し、それを他のコードから分離する方法であるということです。問題の言語にオブジェクトとインターフェイスの継承があり、それを機能させることができる場合、プログラミング言語に依存しないように記述されています。
そうではないのは、ビジネスロジックを構造化し、それをビューコントローラーから分離する方法です。これが、実際に必要とされている説明です。そのために利用可能な他の多くのオプションがあります。私が作業している場所では、ビジネスロジックを提供する一連のServiceオブジェクトを記述し、コントローラーはそれらを呼び出します（それらには、DIフレームワークによってリポジトリオブジェクトが挿入され、詳細をすべて知らなくてもデータストレージにアクセスできるようになります）。コントローラーには、UIからの着信データをサービスが処理できる形式に処理し、サービス応答をユーザーへの表示に適したものに変換するコードのみが含まれます。