asp.net-mvc - 存储库模式 : good or bad?

Question

在阅读了 ASP.NET MVC 3.0 项目中存储库设计模式的好处(和使用)后，我遇到了一个让我感到困惑的问题，并开始质疑该模式的好处。也许有人可以帮我澄清这一点。

我有以下 3 个表:

- 用户 ( parent )

- 用户线索 ( child of User )

- 用户线索 ( child of UserLead )

粗略地说，表和它们之间的关系是这样设计的:

用户 [身份证]

用户线索 [Id, UserId (外键)]

用户线索 [Id, UserLeadId(外键)]

我有一个包含基本 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 表 不在 UserId 上有外键，我需要做的是添加一个

.Include(“UserLead’)

在我的 _userLeadNoteRepository有类似的东西:

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

然后我会删除刚刚找到的 UserLeadNote 对象:

_userLeadNoteRepository.Delete(userLeadNote);

问题:

按照上述方法，这将迫使我 a)为我的 UserLeadNotes 和 b) 创建一个存储库由于 .Include()，找到的 userLeadNote 对象将有一个名为 UserLead 的属性。保存 UserLead 表中定义的所有字段。

如果我的 UserLead 表恰好有 14 个字段，其中 10 个字段是 ntext，那意味着我将无缘无故地加载/保存太多信息!

如果我要使用绕过存储库并直接使用我的上下文的 Linq 语句而不是 Lambda 表达式:

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 语句直接使用他们的上下文。

两恶孰轻？

Answer 1

综上所述，

阅读 Ryan 和 Rouen 的帖子后，似乎为每个实体创建一个存储库可能不是合适的方法。如果我有一个 child (或 child 的 child )实体，我应该创建一个单一的父存储库并通过 child (或 child 的 child )导航我的方式。

我面临的问题是，当试图删除子实体的子实体(没有父实体的外键)时，我必须.Include(“”)那些其他的“上层” table 。 (在我的情况下，它只有一个表，父表，但很容易删除一个 child 的一个 child 的 child ，并且必须 Include() 许多“ parent /上层”表)。

最后，Include the Parent table 创建了一个属性，该属性包含 Parent 的所有字段，在我的情况下，这被认为是为我手头的简单任务“获取”太多信息。

如果我放弃使用 Repository Pattern 而直接使用 Context，这个所谓的问题是可以避免的。

对于一些人来说，这可能不是问题(或者他们根本不知道发生了什么)，而对于其他人来说，拥有模式比它可能具有的缺点更重要。

我还没有决定完全放弃 Repository Pattern，因为我喜欢它带来的东西。

谢谢大家。