实体框架 - 无存储库抽象

在我的项目中，我需要使用EF并抽象表示层中的查询。根据我一直在网上阅读的问题和答案，EF构建了DbSet上的存储库模式和DbContext上的工作单元。实体框架 - 无存储库抽象

存储库模式可以很容易地做到这一点，但我不想重复这个实现，现在混淆了我应该在哪里初始化或访问DbContext。它应该在服务层上吗？

MVC4 API将被用于这个项目，我已经看到在过去的这个工作

2012-11-22 gnaungayan

如果你不想自己的存储库层......还有其他地方？ –

好吧，这并不是我完全想要抓取存储库，我只是不想创建一个类似于其他教程的新存储库实现。 IDbSet是否会在这款游戏中扮演重要角色？ – gnaungayan

我认为DbContext的存储库问题存在一些困惑。我正在开发一个WPF - MVVM应用程序，并且我最终没有使用仓库，而只是使用内置的dbSet，它运行得很好。我有兴趣听到别人对这个问题的意见。 – GetFuzzy

一种方式是通过为您的上下文中的接口，以去除基本上一个物理数据库上的DbContext的依赖则使您的数据访问代码从您的服务层（业务逻辑层）。

然而，使用这种方法有一个缺点，那就是你的单元测试（它将使用你的DbContext的伪实现）将使用LINQ to Objects来运行你的查询，而你的具体实现将会使用不支持所有LINQ to Objects方法的LINQ to Entities。

有MSDN文档（http://msdn.microsoft.com/en-us/library/bb738550.aspx），它强调了这些差异。

我也推荐阅读这篇文章（http://kearon.blogspot.com.au/2011/02/mocking-entity-framework-4-code-first.html），它演示了如何使DbContext单元可测试消除对财务数据库的依赖依赖。

希望这一切都有帮助！

2012-11-25 06:14:56 Mark

谢谢你的回答。如果我理解正确，我将从服务层访问DbContext？这样做可以吗？那么对于劣势部分，我想我必须在那里做一个整合测试 – gnaungayan

是的，它绝对没问题;这样做会有效地消除对底层数据存储的依赖。而集成测试肯定会使不兼容性浮出水面。 – Mark

谢谢梅兹。我认为这是我正在寻找的答案 – gnaungayan

回答