我知道这与SO中不能容忍的自以为是的问题非常接近，所以我想说清楚 - 我不是在问什么是Repository Pattern + UOW的最佳替代品，但可以使用什么代替。
我是Entity Framework爱好者。大约在一年前被引入.NET技术，DbContext和DbSet已经成为Entity Framework的一部分，所以讨论已经存在，我读了一个很多关于上下文如何是我们的通用存储库以及DbSet如何是我们的UOW，而现在如果你必须考虑使用某种进一步的抽象，它主要有利于执行测试和简化不同之间切换的能力{ {1}}。
嗯，这可能是真的，但是有很多关于Repository模式的文章，我们真的需要它，OR/Ms变成了什么等等，所以我做了下一步 - 如果Entity Framework并且Repository pattern不是过去与UOW（5+）的新版本相结合的，那么现代方法是什么，现在还有哪些其他选项可以更好地利用EF Entity Framework 1}}开箱即用？所以，问题是从字面上看，我最终没有任何特别的结果。没有什么可以远离教程，甚至是关于如何使用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();
}
显然在整个应用程序中都有重复的代码，在它自己的方法，项目......数据访问层中分离它似乎很自然......所以这是我发现的第一件事{{1 - 它允许我们保持干燥，这总是很好。
我在使用Repository pattern时总是欣赏的第二件事是，当涉及到更具体的查询时，它会检索您应该从多个方法中使用的信息。因此，例如，如果我需要一些方法，例如：Repository pattern并且拥有一个存储库，那么编写此方法一次非常容易，然后只需在需要的地方调用它，更不用说如果需要更改，维护是多么容易这个方法中的东西和业务逻辑只在一个地方，你不必去每个方法并重写这段特定的代码。
所以也许还有更多可以写的关于这个，但是，这是我在所有应用程序中注意到的事情，所以我一直在努力，所以我真的很感兴趣。什么是现代方法？我主要谈论的是中小型应用程序。
答案 0 :(得分：2)
Repository + EF周围有很多变种，因此很难说出你所指的是 Repository Pattern + UOW 。也许您可以发布自己的一个存储库，以便我们提出建议？
许多＆＃34; no-repository＆＃34;最近萌芽的咆哮真的是对存储库模式错误的咆哮。也许群众最近一直在广泛滥用它，这就是为什么这些人想要禁止它 - 但是他们错了。如果你坚持原来的意义，那么Repository就没什么不好 - 一个看似内存集合的对象来查询或添加，但映射到封面下的另一层。分别理解每个模式也有帮助。存储库！=工作单元，一些存储库实现可能根本不使用UoW。
如果您的代码示例应该显示我们可以在基本Repository实现中重用的内容，那么它可能是一个糟糕的例子而且是个坏主意。 您不希望强制将工作单元的范围限制为单个Add()或Delete()存储库调用的限制。您想要更高级别的， 执行上下文感知对象，用于控制业务事务，从而控制工作单元。它没有由Repo决定是否以及何时将事情冲到数据库中。