0

几天后我在想......真的有必要将 UoW 和存储库模式与 Entity Framework 5 及更高版本一起使用吗？我的意思是，存储模式的使用方式和目标已经通过 EF 实现（除了您有多个数据源的那些）......并且工作单元用于设置单独的操作......在内部使用 EF 也可以实现...所以我只想问一下，从架构软件设计的角度来看，这些模式是否是一种过度工程实现！

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

谢谢！！！

4

2 回答 2

1

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

工作单元/存储库模式是设计模式。它的构建是为了将业务逻辑与数据访问层解耦，其中有一个中间层公开业务逻辑可以理解的操作，因此业务逻辑不关心数据是如何持久化的。

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

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

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

  • 我会改变我的数据访问层吗？
  • 有时间做单元测试吗？
  • 我需要多少时间/预算来完成这个项目？

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

您 100% 正确认为 DbContext = UnitOfWork 和 DbSet = Repository，但它们只是实现和设计模式要求您的业务逻辑使用 IUnitOfWork 和 I(class)Repository 接口，而不是使用实际实现（再次解耦） .

于 2013-09-20T21:36:36.710 回答
1

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

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

于 2013-09-20T21:43:00.277 回答