描述DbContext说：“DbContext 实例表示工作单元和存储库模式的组合......”。但是许多开发人员倾向于创建自己的存储库和 UoW。
我应该直接使用DbContextandDbSet还是应该有我自己的 Repositories ？有什么区别。
如果我们直接使用有什么问题DbContext吗？如果我将来从 MS SQL 切换到 Oracle 怎么样？
问问题
2549 次
1 回答
5
关注MSDN
其他时候，您可能想要编写自己的应用程序特定的工作单元接口或类来包装来自持久性工具的内部工作单元。您可能出于多种原因这样做。您可能希望将特定于应用程序的日志记录、跟踪或错误处理添加到事务管理中。也许您想从应用程序的其余部分封装持久性工具的细节。您可能需要这种额外的封装，以便以后更容易更换持久性技术。或者您可能想提高系统中的可测试性。来自常见持久性工具的许多内置工作单元实现很难在自动化单元测试场景中处理。
回到你的问题。
我应该直接使用 DbContext 和 DbSet 还是应该有我自己的 Repositories ？
实际上，当您将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使用实体框架时，您只需按照以下链接更改数据提供者。
于 2013-05-03T04:02:33.983 回答