web-dev-qa-db-ja.com

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

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

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

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

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

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

私がこれを尋ねる理由は、GetById、GetByName、GetWithIncludesABC、GetWithIncludes123などの多くのメソッドをリポジトリに追加しているところに行き着いているようで、私の心の中でリポジトリを汚しているようです

asp.net-mvcentity-frameworkrepository
9
Loren.Dorez

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

_GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123
_

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

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

別のリポジトリレイヤーが必要になる可能性があると考えられる唯一の説得力のある理由は、そのリポジトリレイヤーを模擬したり、テスト目的で別のデータソースに置き換えたりできるためです。

12
Robert Harvey

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

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

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

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

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

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

4
Greg Burghardt

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

https://github.com/Microsoft/BikeSharing360_BackendServices

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

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

1
Pavel Biryukov