EF 4和上层需要工作单元和存储库吗？

Question

经过几天的思考......我真的有必要在实体框架5和上层使用UoW和Repository模式吗？我的意思是，存储库模式的使用方式和目标已经通过EF实现（除了那些你拥有多个数据源的那些）...并且工作单元用于设置单独的操作......在内部实现EF也是如此...所以我只是想问一下，在架构软件设计的角度来看，是否过度工程实现了这些模式！

我知道这听起来很傻，但我只是想让事情变得简单而专业。

谢谢!!!

Answer 1

这是一个更实际的决定，而不是“规则”。

工作单元/存储库模式是设计模式。它的构建是为了将业务逻辑与数据访问层分离，其方式是存在一个中间层，该中间层公开业务逻辑可理解的操作，以便业务逻辑不关心数据是如何保持的。

在你可能决定实体框架不是好方法而你想用NHibernate替换它的情况下，这是很好的。您不必再次编写所有业务逻辑，而只需基于NHibernate实现新的工作单元/存储库，并保持业务逻辑不变。

使用此模式的另一个好理由是能否进行单元测试。

可能没有更多好理由，但最终归结为实际决策：

• 我会更改我的数据访问层吗？
• 是否有时间进行单元测试？
• 我有多少时间/预算来完成项目？

对于单个开发人员/较小的项目/预定义框架 - 它只是不必要的抽象层。

你是100％正确的DbContext = UnitOfWork和DbSet = Repository，但它们只是实现和设计模式要求你的业务逻辑与IUnitOfWork和I（类）存储库接口一起使用，而不是与实际的实现一起使用（再次解耦）。

Answer 2

如果您的架构和设计目标要求您的数据访问层不受持久性影响，例如在DDD或n层中，那么可能是必要的;否则，实体框架的DbContext和DbSet已经是您的工作单元和存储库模式。大多数情况下，不需要使用EF抽象冗余的工作单元和存储库模式。

这完全取决于您的要求和设计目标，但即使您想在单元测试（TDD）中执行此操作，它仍然没有那么有用。集成测试对EF更有用，在这种情况下，冗余的工作单元/存储库模式是不必要的。