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つの悪のうちの小さいものは何ですか?
私はいくつかのプロジェクトでこのパターンを使用しましたが、それをドロップしてコンテキストに直接向かいました。引き続きパターンを使用する場合は、**集約ルート**をお読みください。あなたはすべてのテーブル/エンティティ、単にあなたのコアのものにレポを望んでいません。私は通常複雑なビジネスロジック/リレーションシップのために完全なDDDを予約しています。 http://devlicio.us/blogs/casey/archive/2009/02/16/ddd-aggregates-and-aggregate-roots.aspx – Ryan
私のUserLeadとUserLeadNotesテーブルが集計と見なされるようになりました。だから私のUserLeadテーブルは、集計ルートと見なされます。これは、その集約されたルートテーブル用に1つのリポジトリだけを持ち、そのルートから私の子供に移動する必要があることを意味します。これを念頭に置いて、私の単一のUserLeadリポジトリで私の子供に移動し、親の追加フィールドをロードせずにFirstOrDefault()子オブジェクトを取得する方法を教えてください。おそらくあなたは正しいです。私はリポジトリパターンを落とし、私のサービス層から私のコンテキストを直接呼び出し/使用するべきです – Vlince