DbContext的描述说：“DbContext实例代表工作单元和存储库模式的组合......”。但是许多开发人员倾向于创建自己的存储库和UoW。
我应该直接使用DbContext和DbSet还是应该使用我自己的存储库？有什么区别。
如果我们直接使用DbContext会有问题吗？如果我将来从MS SQL切换到Oracle怎么样？
答案 0 :(得分：5)
关注MSDN
其他时候，您可能希望编写自己的应用程序特定单元 工作界面或类包装你的内部工作单位 持久性工具。您可能出于多种原因这样做。你可能会 想要添加特定于应用程序的日志记录，跟踪或错误处理 到交易管理。也许你想封装一下 来自其余部分的持久性工具的细节 应用。您可能希望这种额外的封装使其更容易 以后换掉持久性技术。或者你可能想要 提升系统的可测试性。许多内置的工作单元 来自常见持久性工具的实现很难处理 在自动化单元测试场景中。
回到你的问题。
我应该直接使用DbContext和DbSet还是应该使用我自己的 存储库？
事实上，将DbContext和DbSet放入存储库时没有问题。我们自己会问，我们想更容易测试。如果我们想要设计一个测试所有内容的框架，我们就不应该直接将DbContext和DbSet用于Repositories。我们应该使用用于提供IDbContextFactory的接口DbContext，只需要我的两分钱。
为了帮助您获得有关存储库的许多视图，您可以参考下面的链接来考虑存储库和DbContext之间的选项。
http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/
如果我们直接使用
DbContext会有问题吗？
不，如果您直接使用DbContext，则没有问题。但它会扰乱许多业务规则和大量扩展问题，因为集中数据库，难以测试和违反设计原则中的单独关注。
如果我将来从MS SQL切换到Oracle怎么样？
实际上，将来在MS SQL和Oracle之间切换时没有问题。您只需在使用实体框架的DbContext时按照以下链接更改数据提供者。