リポジトリパターン：良いか悪いですか？

Question

ASP.NET MVC 3.0プロジェクトのリポジトリデザインパターンの利点を読んだ後、私は困惑してパターンのメリットを疑問に思っていました。おそらく誰かが私にこれを明確にする助けとなるかもしれません。

I持って、次の3 TABLES：

• - ユーザー（parent）
• - UserLead（child of User）
• - UserLeadNotes（child of UserLead）

大雑把に、テーブルとその関係は、このように設計されています：

• ユーザー[ID]
• UserLead[ID、ユーザーID（外部キー）]
• UserLeadNotes[Id、UserLeadId（Foreign Key）]

私は基本的なCRUDメソッドを含むBaseRepositoryを持っています。代わりにそれと (IEnumerable<TEntity> Get(), TEntity GetByID(), Insert(), Delete(), etc…)

、私はまた、必要に応じて適切なリポジトリを呼び出すService Layerを持っています。

簡単に言えば、アプリケーションはUserLeadを表示し、ユーザーはUserLead（UserLeadNotesテーブルに保存/削除されている）にメモを追加/削除することができます。ノートの追加/削除はAjaxコールを介して行われます。ノートのを削除すると、ノートの“id”に沿ってノートのが削除されます。私は実際にノートを削除する前に

は今...、私はノートが本当に現在ログインしているユーザーに属していることを確認する必要があります（User.Identity.Name aka UserId）

が私の方法を考えるdeleteUserNote(int noteId)はとがあることを考慮“noteId”パラメータを受け取り、私UserLeadNotesはTABLE がは私が何をする必要があるかUserId、上の外部キーを持っていない、

を追加することです。

_userLeadNoteRepository.Delete(userLeadNote); 

---

：それから私は、私はちょうど見つけ UserLeadNoteオブジェクトを削除します

UserLeadNote userLeadNote = _userLeadNoteRepository 
       .AllIncluding(p => p.UserLead) 
       .FirstOrDefault(p => p.UserLeadNoteID.Equals(noteId) 
        && p.UserLead.UserID.Equals(User.Identity.Name)); 

：のようなものを持っている（「UserLead '）私の_userLeadNoteRepository内部

を含めます

質問：

これにより、UserLeadNotesとb)のリポジトリを作成するために、私はa)のリポジトリを作成しなければなりません。見つかったuserLeadNoteオブジェクトは、UserLeadテーブルに定義されたすべてのフィールドを保持するUserLeadというプロパティを持ちます。

私のUserLeadテーブルが14フィールドを持ち、これらのフィールドのうちの10個がntextの場合、それは何もロード/保持しないことを意味します。私はラムダ式の代わりに、を使用していた場合は

、LINQの文がリポジトリをバイパスし、直接私のコンテキストを使用します。

using(MyContext db = new MyContext()) 
      { 
       var query = 
        from uln in db.UserLeadNote 
        join ul in db.UserLead on uln.UserLeadID equals ul.UserLeadID 
        where uln.UserLeadNoteID == userLeadNoteID 
         && ul.UserID == User.Identity.Name 
        select uln; 

       var userLeadNote = query.FirstOrDefault(); 

       db.UserLeadNote.Remove(userLeadNote); 

       db.SaveChanges(); 
      } 

は、このアプローチは、それがないだろうとして、より効率的ではないでしょうこれらの不要なフィールドをUserLeadテーブルから戻しますか？ （たとえば、10 ntextフィールド）。

私がリポジトリパターンを正しく使用していない場合、またはこれがEntity Frameworkの問題である場合を除き、誰かが何を考えているか知りたいです！

リポジトリパターンを適切に配置することのメリットを認識していますが、これは人々が持っているかどうかにかかわらず問題がある場合は気になります。もしそうなら、彼らはパターンを落とし、Linqステートメントを使ってContextを直接使用することに決めましたか？

2つの悪のうちの小さいものは何ですか？

Answer 1

の悪用のこの種についての説明/意見と私の答えがあり、

ライアンのを読んだ後とルーアンの記事では、エンティティごとに1つのリポジトリを作成することは適切なアプローチではないようです。私が子（または子の子）エンティティを持っている場合、代わりに単一の親リポジトリを作成し、子（または子の子）を経由して移動する必要があります。

私が直面していた問題は、（親の外部キーを持たない）子エンティティの子を削除しようとしたときに、他の「上位」テーブル.Include(“”)にあったということでした。 （私の場合、それは1つのテーブルだけでしたが、親テーブルは1つの子供の子供を簡単に削除する必要があり、Include()多くの "親/上位"テーブルが必要です）。

最後に、親テーブルを含めて、親のすべてのフィールドを保持するプロパティを作成しました。私の場合は、手元の簡単なタスクの情報が多すぎるとみなされました。

リポジトリパターンの使用を中止し、代わりにコンテキストを直接使用すると、このような問題が回避できます。

これは問題ではないかもしれません（あるいは、何が起こっているのか分かりません）。そして、パターンが所定の位置にあると、それが持つ可能性のある短所を上回るものがあります。

私はリポジトリパターンを完全に削除することを決断しませんでした。なぜなら、私はそれがテーブルにもたらすものが好きだからです。

ありがとうございます。

Answer 2

ここを見てしよう：

asp.net mvc page is not showing properties from associated objects

結論として、一般的なリポジトリパターン