如果是，那么我们就完成了......使用EF（使用DbContext）时无需设计和实现repos和工作单元
也许我错过了什么，但对我来说，DbContext实现了一个完美的UnitOfWork（接口缺少... :-(），而它的.Set是实体T的通用回购。
为什么然后人们继续实施正在使用/拥有上下文的repos，并实现正在使用/拥有更多repos的作品单元？他们使用相同设计模式的实现来实现设计模式。
（我知道：EF DbContext没有实现适合UnitOfWork / Repo模式的可用接口，但除此之外，我错过了什么？）
提前谢谢
答案 0 :(得分：2)
是的，它们是工作单元和存储库模式的实现 我认为，当您计划将数据访问逻辑与存储库级别分开时，您需要使用自己的存储库或工作单元的唯一情况。这意味着如果您稍后将使用另一种访问数据库的方式（如Nhibernate），那么很容易拥有自己的存储库层。
如果你需要另外一种类型的数据源而不仅仅是实体框架，那么最好为你的数据访问设置一个抽象层。
答案 1 :(得分：0)
你是对的。
但是如果他们错过了一些功能，那么人们正在已经存在的情况下实现他们的自定义版本（例如，DbSet太通用了，缺乏查询重用的可能性（例如，使用规范模式）。）