.net - 创建我们自己的 UoW/Repository 与直接使用 DbContext 之间的区别

Question

DbContext 的描述说:“一个 DbContext 实例代表了工作单元和存储库模式的组合......”。但是许多开发人员倾向于创建自己的存储库和 UoW。

我应该使用 DbContext和 DbSet直接还是应该有我自己的存储库？有什么区别。

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

Answer 1

关注 MSDN

Other times, you may want to write your own application-specific Unit of Work interface or class that wraps the inner Unit of Work from your persistence tool. You may do this for a number of reasons. You might want to add application-specific logging, tracing, or error handling to transaction management. Perhaps you want to encapsulate the specifics of your persistence tooling from the rest of the application. You might want this extra encapsulation to make it easier to swap out persistence technologies later. Or you might want to promote testability in your system. Many of the built-in Unit of Work implementations from common persistence tools are difficult to deal with in automated unit testing scenarios.

回到你的问题。

Should I use DbContext and DbSet directly or should be there my own Repositories ?

其实放 DbContext的时候是没有问题的和 DbSet到您的存储库中。我们会问自己，我们想测试更容易还是不想测试。如果我们想设计一个框架来测试我们不应该使用的所有东西 DbContext和 DbSet也可以直接进入您的 Repositories .我们应该使用接口(interface) IDbContextFactory用于提供 DbContext ，只是我的两分钱。

为了帮助您对存储库有更多的看法，您可以引用下面的链接来考虑存储库和 DbContext 之间的选项。 .

http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/

Is there any problem if we use the DbContext directly ?

不，如果你使用 DbContext没有问题直接地。但是它会弄乱许多业务规则和大量的扩展问题，例如集中式数据库、难以测试和违反设计原则中的关注点分离。

How about if I switch from MS SQL to Oracle in the future ?

实际上，以后在 MS SQL 和 Oracle 之间切换是没有问题的。您只需在使用 DbContext 时更改数据提供者，请点击以下链接 Entity Framework 。

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

或者
MS Entity Framework Oracle Provider