2

NerdDinner のチュートリアルをチェックしてきました。LINQ to SQL と MVC2 を使用する元の PDF チュートリアル ( http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf ) を読んでいました。そのチュートリアルでは、データ コンテキストを実装してから、リポジトリ クラスを実装してデータ エンティティと対話します。

MVC4 と Entity Framework ( http://nerddinner.codeplex.com ) を使用するようにプロジェクトが更新されたので、そのコードを参照して、実装された変更を確認しました。彼らはプロジェクトをコード ファーストに変更し、データ エンティティごとに個別のモデル クラスを使用しました。リポジトリが完全に削除されたことに驚きました。

リポジトリ パターンを介してデータベースとの通信を抽象化することは、一般的には良い方法だと思いました... チュートリアルは、簡潔にするために設計上の選択を誤っていることが多いことは知っていますが、リポジトリを既に実装しているチュートリアルがなぜ決定を下したのか疑問に思っています。このバージョンからそれらを省略します。

MVC4 または EF に、リポジトリを廃止/冗長にするものはありますか?

4

2 に答える 2

10

Entity Framework のような高度な抽象化をリポジトリにラップすることに意味があるかどうかについては、長い議論があります。

歴史的に、リポジトリは素晴らしいものでした。DataSet異なるデータ プロバイダー、プレーン オールドs、ファイル、linq などを切り替えることができるようにするためだけに、追加の抽象化レイヤーを用意することは安全でした。

ただし、多くの EF 純粋主義者は、EF は既に作業単位とリポジトリの抽象化であり、データ コンテキストが作業単位であり、dbset がリポジトリであると主張しています。彼らは、LINQ はクエリ言語の十分な抽象化であり、特定の制限された API は必要ないと主張しています。

同じ LINQ クエリに対して一貫した結果を提供するという意味で、考えられるすべてのプロバイダーに互換性があると仮定するのは安全ではないと言う人もいます。一部のプロバイダーは制限され、特定のクエリの評価を拒否することさえあります。これは - 人々が言うには -上位レイヤーに対して同じデータ コントラクトを保証するために、EF を介した抽象化がまだ必要であることを意味します。

誰かが例からリポジトリ レイヤーを削除することを決定した場合、これは次の 2 つの理由のいずれかが原因である可能性があります。

  • リポジトリは例をより複雑にするだけであることに誰かが気づき、単純化のためにそれらを削除しました
  • EF 純粋主義者である誰かが、「EF の上に立つものは何もない」という事実を提唱したいと考えています。

個人的にはリポジトリが好きで、可能な限り使用しています。

于 2013-09-27T20:11:30.363 に答える
4

CQRSの人気が高まるにつれ、Jimmy Bogard のような人々がその使用に対して良い事例を作っているため、Repository パターンは少し支持されなくなりつつあります。

基本的に、 SRPに違反して、多数の異なるクエリを形成する方法を知っている大規模なクラスとしてリポジトリが終了するのは簡単です。複雑なシステムでこれを回避すると、最終的に多くのリポジトリが作成される可能性があり、単純なシステムでリポジトリを使用することは、オーバーエンジニアリングです。

于 2013-09-27T20:19:45.840 に答える