在应用程序中访问DbContext是非常糟糕的做法吗？

Question

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

因此，最好将DbContext作为存储库的成员访问，例如简单方法，而不是通过存储库包装它们。你觉得怎么样？

Answer 1

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

请记住也使用IDbSet而不是DbSet来使其易于模拟。

Answer 2

直接在业务逻辑中使用DbContext或（天堂禁止！）显示逻辑代码是严重违反“关注分离”原则，并倾向于使您的代码：

• 难以维护：如果您决定重构DbContext的创建方式，那么现在必须查看整个代码库以更改每个new DbContext。
• 难以进行单元测试：实体框架上下文非常难以“模拟”，而界面上的简单存储库方法很容易被模拟以返回一些样本数据。