Ler*_*ica 7 design-patterns entity-framework
我知道这是非常接近自以为是的问题,这是不容忍的,SO所以我想说清楚 - 我不是问什么是Repository Pattern + UOW的最佳替代品,而是可以使用什么.
我是一个Entity Framework狂热爱好者.被介绍到.NET技术大约一年前,当,DbContext并且DbSet已经部分Entity Framework这样的讨论已经在那里了,我已经读了很多有关上下文如何是我们通用的存储库,以及如何DbSet为我们的UOW和时下,如果你必须考虑使用某种进一步的抽象,它主要有利于执行测试和简化不同之间切换的能力OR/Ms.
好吧,它可能是真的,但是有很多关于Repository模式的文章,我们真的需要它,Entity Framework已经变成了什么等等,所以我做了下一步 - 如果Repository pattern和UOW不是过去与新版本的结合EF(5+)那么现代的方法是什么,我们现在可以使用哪些其他选项来更好地利用Entity Framework开箱即用的优惠？所以,问题是从字面上看,我最终没有任何特别的结果.没有什么东西可以远离教程,甚至是关于如何使用它的一个很好描述的想法EF所以这是最终在这里写一个问题的主要原因.
我真正喜欢的Repository pattern和它的工作方式是保持分离的能力.我的意思是我看到人们在每个需要DB访问的方法中字面写字:
using (var context = new MyDbContext())
{
Product prod = new Product();
prod.Name = "Something";
prod.Price = 10;
context.Products.Add(prod);
context.SaveChanges();
}
显然在整个应用程序中都有重复的代码,并且在它自己的方法,项目......数据访问层中分离它似乎很自然......所以这是我发现的第一件好事Repository pattern- 它允许我们保持干,这总是很好.
我在使用Repository pattern时总是欣赏的第二件事是,当涉及到更具体的查询时,它会检索您应该从多种方法中使用的信息.因此,例如,如果我需要一些方法,例如:GetAllDataForUsersWithMoreThanTenPurchasesPerMonth()并且拥有一个存储库,很容易编写一次这个方法,然后只需要在任何需要的地方调用它,更不用说如果你需要在这个方法中改变一些东西,维护是多么容易业务逻辑只在一个地方,你不必去每个方法并重写这段特定的代码.
所以也许可以写更多关于这个但是,这是我在所有应用程序中注意到的,我一直在努力,所以我真的很感兴趣.什么是现代方法？我主要谈论的是中小型应用程序.
围绕 Repository + EF 有数十种变体，因此很难说出您所指的Repository Pattern + UOW。也许您可以发布您自己的存储库之一，以便我们提出建议？
最近出现的许多“无存储库”的抱怨实际上是针对存储库模式滥用的抱怨。也许大众最近广泛滥用了它，这就是为什么这些人想要禁止它 -但他们错了。如果您坚持其最初的用途，那么存储库并没有什么不好——一个看起来像内存中集合的对象，可以从中查询或添加到其中，但在幕后映射到另一层。单独理解每种模式也有帮助。存储库！=工作单元，并且某些存储库实现可能根本不使用 UoW。
如果您的代码示例应该显示我们可以在基本存储库实现中重用的内容，那么它可能是一个坏例子，也是一个坏主意。您不想将工作单元的范围强制限制在单个Add()或Delete()存储库调用的范围内。您需要一个更高级别的、执行上下文感知的对象来控制业务事务，从而控制工作单元。是否以及何时将数据刷新到数据库并不由 Repo 决定。