创建我们自己的UoW/Repository与直接使用DbContext之间的差异

Question

说明DbContext:"DbContext实例代表工作单元和存储库模式的组合......".但是许多开发人员倾向于创建自己的存储库和UoW.

我应该使用DbContext,并DbSet直接或应该有我自己的信息库？有什么区别.

如果DbContext直接使用,有什么问题吗？如果我将来从MS SQL切换到Oracle怎么样？

Answer 1

关注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之间切换时没有问题.您只需在使用DbContextEntity Framework 时更改数据提供者,请按照以下链接进行操作.

http://www.devart.com/news/2008/directs475.html

或 MS实体框架Oracle提供程序