为什么我应该在我的 EF 顶部构建一个包含工作单元的存储库模式？
Why should i build a repository pattern with a unit of work on the top of my EF?
根据MSDN DbSet :
DbSet<TEntity> Class
A DbSet represents the collection of all entities in the context, or
that can be queried from the database, of a given type. DbSet objects
are created from a DbContext using the DbContext.Set method.
并且根据 MSDN DbContext :
DbContext Class
A DbContext instance represents a combination of the Unit Of Work and
Repository patterns such that it can be used to query from a database
and group together changes that will then be written back to the store
as a unit. DbContext is conceptually similar to ObjectContext.
以便 EF 在内部使用 repository pattern 和 UOW。
DbSet <----> Repository
DbContext <----> Unit Of Work
为什么我应该在我的 EF 顶部构建一个包含工作单元的存储库模式？
Why should i build a repository pattern with a unit of work on the top of my EF?
取决于您希望如何管理依赖项。
如果 Entity Framework 是您的抽象层并且数据库本身是依赖项，那么 Entity Framework 确实已经提供了您的存储库和工作单元。权衡是您的域依赖于 Entity Framework。只要这种依赖性是可以接受的，你就很好。
另一方面，如果您想将 Entity Framework 本身视为可以在不更改域代码的情况下被换出的依赖项，那么您需要创建一个抽象作为包装器在那附近。
基本上，这一切都归结为您划清界线的地方是或不是 "external dependency"。对于某些项目来说，这无关紧要，对于某些项目，它是物理数据库，对于某些项目，它是数据访问框架等。
Why should I build a repository pattern with a unit of work on the top
of my EF?
因为Interface Segregation Principle。 DbSet 和 DbContext 中的方法签名基本上是一个大的低级混乱，它们与存储库和工作单元中通常预期的内容之间存在巨大的不匹配。换句话说，如果您直接使用 DbSet 和 DbContext，您的应用程序服务代码将遭受泄漏抽象。
在您的应用层中，您需要操作适当的语义。该层中的代码只需要根据 业务交易 和大型 集合 进行交流，您可以在其中获取和存储内容。这些是非常高级的、极简主义的抽象概念。 Entity Framework 行话太模糊和低级了，因此您需要介绍其他习语 - Repository 和 UoW。
根据MSDN DbSet :
DbSet<TEntity> Class
A
DbSet represents the collection of all entities in the context, or that can be queried from the database, of a given type. DbSet objects are created from a DbContext using the DbContext.Set method.
并且根据 MSDN DbContext :
DbContext Class
A
DbContext instance represents a combination of the Unit Of Work andRepository patternssuch that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.
以便 EF 在内部使用 repository pattern 和 UOW。
DbSet <----> Repository
DbContext <----> Unit Of Work
为什么我应该在我的 EF 顶部构建一个包含工作单元的存储库模式？
Why should i build a repository pattern with a unit of work on the top of my EF?
取决于您希望如何管理依赖项。
如果 Entity Framework 是您的抽象层并且数据库本身是依赖项，那么 Entity Framework 确实已经提供了您的存储库和工作单元。权衡是您的域依赖于 Entity Framework。只要这种依赖性是可以接受的，你就很好。
另一方面，如果您想将 Entity Framework 本身视为可以在不更改域代码的情况下被换出的依赖项，那么您需要创建一个抽象作为包装器在那附近。
基本上，这一切都归结为您划清界线的地方是或不是 "external dependency"。对于某些项目来说，这无关紧要，对于某些项目，它是物理数据库，对于某些项目，它是数据访问框架等。
Why should I build a repository pattern with a unit of work on the top of my EF?
因为Interface Segregation Principle。 DbSet 和 DbContext 中的方法签名基本上是一个大的低级混乱，它们与存储库和工作单元中通常预期的内容之间存在巨大的不匹配。换句话说，如果您直接使用 DbSet 和 DbContext，您的应用程序服务代码将遭受泄漏抽象。
在您的应用层中，您需要操作适当的语义。该层中的代码只需要根据 业务交易 和大型 集合 进行交流，您可以在其中获取和存储内容。这些是非常高级的、极简主义的抽象概念。 Entity Framework 行话太模糊和低级了，因此您需要介绍其他习语 - Repository 和 UoW。