我通常会看到封装了 CRUD 方法甚至是简单的扩展方法的存储库模式示例。我发现创建 DbContext 已经可以轻松使用的存储库方法真的很烦人。如果原因是在 DbContext 和整个应用程序之间创建松散耦合,那么我们已经可以通过将 DbContext 提取到接口并在整个应用程序中使用它来做到这一点。
因此,对于简单的方法,将 DbContext 作为存储库的成员访问而不是通过存储库包装它们看起来更好。你怎么看 ?
我通常会看到封装了 CRUD 方法甚至是简单的扩展方法的存储库模式示例。我发现创建 DbContext 已经可以轻松使用的存储库方法真的很烦人。如果原因是在 DbContext 和整个应用程序之间创建松散耦合,那么我们已经可以通过将 DbContext 提取到接口并在整个应用程序中使用它来做到这一点。
因此,对于简单的方法,将 DbContext 作为存储库的成员访问而不是通过存储库包装它们看起来更好。你怎么看 ?
虽然原则上我同意 StriplingWarrior 的想法,但如果您正在构建一个更简单的架构,其中您的业务层使用 DbContext 属性/方法,那么它没有任何问题,特别是如果您使用 DbContext 的接口并注入它。
请记住还要使用 IDbSet 而不是 DbSet 以使其易于模拟。
直接在业务逻辑内部使用 DbContext 或(天堂禁止!)显示逻辑代码是严重违反“关注点分离”原则的,并且往往会使您的代码:
new DbContext
.