抽象出一個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提供者

回答

相關問題