1

我通常会看到封装了 CRUD 方法甚至是简单的扩展方法的存储库模式示例。我发现创建 DbContext 已经可以轻松使用的存储库方法真的很烦人。如果原因是在 DbContext 和整个应用程序之间创建松散耦合,那么我们已经可以通过将 DbContext 提取到接口并在整个应用程序中使用它来做到这一点。

因此,对于简单的方法,将 DbContext 作为存储库的成员访问而不是通过存储库包装它们看起来更好。你怎么看 ?

4

2 回答 2

4

虽然原则上我同意 StriplingWarrior 的想法,但如果您正在构建一个更简单的架构,其中您的业务层使用 DbContext 属性/方法,那么它没有任何问题,特别是如果您使用 DbContext 的接口并注入它。

请记住还要使用 IDbSet 而不是 DbSet 以使其易于模拟。

于 2011-02-11T21:25:29.950 回答
1

直接在业务逻辑内部使用 DbContext 或(天堂禁止!)显示逻辑代码是严重违反“关注点分离”原则的,并且往往会使您的代码:

  • 更难维护:如果您决定重构 DbContext 的创建方式,您现在必须查看整个代码库以更改每个new DbContext.
  • 更难进行单元测试:众所周知,实体框架上下文很难“模拟”,而接口上的简单存储库方法可以很容易地被模拟以返回一些示例数据。
于 2011-02-11T20:42:57.017 回答