ASP.net 5とEF7でリポジトリはもう必要ですか？

EFチームにgithubで質問を投稿しました。ここでこの質問をする方がよいとの返信がありました。コピーしてここに貼り付け、リンクとして他のユーザーがGitHubでいくつかの返信を確認できるようにします。

質問：私はいくつかの調査を行っていましたが、誰かがDBContextクラスの24行目で次のように述べていると指摘しました

DbContextは、作業単位パターンとリポジトリパターンの組み合わせです。

これは、EFをリポジトリーに抽象化し、インターフェースを使用してそれをコントローラーに注入する必要がなくなったことを意味しますか？

Githubの元の投稿：https : //github.com/aspnet/EntityFramework/issues/4899

私がこれを尋ねる理由は、GetById、GetByName、GetWithIncludesABC、GetWithIncludes123などの多くのメソッドをリポジトリに追加しているように見えて、私の心の中でリポジトリを汚しているように思われるからです。

あなたがリポジトリにメソッドを追加している場合

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

次に、サービス層に移動し、サービス層に EFを直接使用させることをお勧めします。EFには、上記の方法と同様の機能がすでにあり、無限に複製しています。

サービス層はビジネスドメインメソッドを公開し、CRUDを使用してそれらを実装します。たとえばTransferMoney(A, B)、AとBがアカウントをチェックしているというメソッドがあるとします。これにより、サービスドメインがCRUDを処理する一方で、ビジネスドメインの言語を話すことができます。

別のリポジトリレイヤーが必要になると思われる唯一の説得力のある理由は、そのリポジトリレイヤーを模擬したり、テスト目的で別のデータソースを代用したりできるようにするためです。

ロバートハーベイは彼の答えで言った：

別のリポジトリレイヤーが必要になると思われる唯一の説得力のある理由は、そのリポジトリレイヤーを模擬したり、テスト目的で別のデータソースを代用したりできるようにするためです。

これが、リポジトリパターンが依然として関連する理由です。Entity Frameworkチームがリポジトリパターンを実装しているという主張にも同意しません。Entity Frameworkは、依然としてデータベースに非常に密接に関連付けられています。リポジトリパターンの主な目的は、アプリケーションで使用されている正確な永続化メカニズムを分離して抽象化することです。これにより、データアクセスの実装から、リポジトリレイヤーの外に漏れることはありません。

ある種のサービスオブジェクトのように、「リポジトリ」の外でEFクエリAPIを使用している場合、パターンを壊していると言えます。

ここで、機能のようなデータベースが他のコードにリークすることは致命的な問題ではなく、将来的に一部のCRUD操作をWebサービスに移動する必要がないことを保証できれば、EFを直接使用することになりますOK。

基本的に、Entity Frameworkは、リポジトリパターンのゲートウェイオブジェクトの代わりをします。私はそれ自体をリポジトリとして見ていません。

リポジトリは必要ないようです-マイクロソフトのサンプルバックエンドマイクロサービスアプリケーションではそれらを使用していません。

https://github.com/Microsoft/BikeSharing360_BackendServices

サンプルのBikeSharingアプリがConnect（）;に表示されました。イベント（APIプロジェクトのテンプレートとして使用できると思います）：

https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/