如果是，那么我们就完成了...使用 EF（使用 DbContext）时无需设计和实现存储库和工作单元
也许我错过了一些东西，但对我来说，DbContext实现了一个完美的Work单元（接口丢失了... ：-（ ）及其.集是实体 T 的泛型存储库。
那么为什么人们继续实现正在使用/具有上下文的存储库，并实现正在使用/具有多个存储库之一的工作单元？他们使用相同设计模式的实现实现设计模式。
（我知道：EF DbContext 没有实现适合 UnitOfWork/Repo 模式的可用接口，但除此之外，错过了我的东西？
提前感谢
是的，它们是工作单元和存储库模式的实现。
我认为您需要使用自己的存储库或工作单元的唯一情况是当您计划将数据访问逻辑与存储库级别分开时。这意味着如果您以后打算使用其他方式访问数据库（如Nhibernate），那么拥有自己的存储库层很容易。
此外，如果您需要拥有其他类型的数据源，而不仅仅是实体框架，那么最好像这样为数据访问提供一个抽象层。
你是对的。
但是，如果人们错过了一些功能（例如，DbSet 过于通用，缺乏查询重用的可能性（例如，规范模式）），他们就会在现有版本的基础上实现他们的自定义版本。