抽象出一个ORM提供者

在我的ASP.NET MVC 3应用程序中，我现在要使用EF4.3作为ORM框架。我希望有能力在未来需要时替代它。这需要定义一个接口，在EF的情况下将指向DbContext实现。抽象出一个ORM提供者

我在界面中为可查询对象定义了什么？

例如在我的情况，我要做到以下几点，但不知道这是否是去一个正确的方法：

在我的接口：

IQueryable<AnonymousUser> AnonymousUsers { get; } 

    int SaveChanges();

在我的DbContext

：

public DbSet<AnonymousUser> AnonymousUsers { get; set; } 

    IQueryable<AnonymousUser> IThoughtCatStorage.AnonymousUsers 
    { 
     get { return AnonymousUsers; } 
    }

正如您所看到的，使用IQueryable是将DbSets抽象出来的一种方法。

这是最好的方法吗？（我知道这听起来颇为讨论，但我只想知道是否目前有一种更一般的方式来定义ORM访问接口。）

来源

2012-02-16 Maxim V. Pavlov

这可能不是一个好主意：http://stackoverflow.com/questions/1699607/asp-mvc-repository-that-reflects-iqueryable-but-not-linq-to-sql-ddd-how-to- que/1699756＃1699756 – 2012-02-16 13:23:25

抽象的价格可能会太高：http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal – 2012-02-16 13:34:33

我已经写了一篇关于这个：

Faking your LINQ provider part 1

来源

2012-02-16 13:26:11 Steven

Steven ，你的文章让我阅读并思考了一个小时左右。虽然我理解了体系结构部分，但是我对Linq To SQL和Unit Testing缺乏了解，这让我怀疑，因为我需要这个用于我的个人项目，所提供的方法可能会给我带来很大的开销。但是，也许，当你有时间时，你可以用DbContext（EF4 code-first）编写一个DataMapper实现？ – 2012-02-16 14:38:28

不要到处使用OR/M。使用存储库类来抽象OR/M，并使单元测试代码更容易。它还消除了代码重复，并且使将来更容易维护代码。

您的好处是，如果将来需要切换OR/M，则只需更改存储库类。

不要忘了，我们都选择一个OR/M的原因（你最喜欢的OR/M的功能）。通过将通用OR/M层后面的OR/M抽象出来，您也可以删除使用这些功能的可能性。

来源

2012-02-16 13:34:23 jgauffin

我同意你的意见。在我指出的文章中，我解释说LINQ是一个漏洞抽象。如果您真的想交换OR/M实现（例如从EF切换到Azure），则不能在您的Repository类之外使用IQueryable。 – Steven 2012-02-16 22:17:52

抽象出一个ORM提供者

回答

相关问题