2009-06-12 55 views

回答

8

在某些方面,它可以感覺像一個活躍的記錄模式,但它確實不是。基本例如:

//load the entity 
var c = myDataContext.Customers.FirstOrDefault(c => c.Id == 1876); 
c.Name = "George Armstrong Custer"; 
// saves the entity 
myDataContext.SubmitChanges(); 

活動記錄

//load the entity 
var c = Customer.GetCustomer(9); 
c.Name = "Varus"; 
//save the entity 
c.Save(); 

活動記錄真的只是涉及一類覆蓋模型,並提供數據接口的LINQ到SQL如下那裏有幾個模型類不同的路徑和一個單獨的數據接口,也稱爲存儲庫。

PS:有關使用活動記錄模式的ORM的一個很好的示例,請查看Subsonic

3

LINQ to SQL本身並不是ActiveRecord模式的實現。在Fowler的ActiveRecord模式的真實實現中,對象本身將負責從數據庫中保存和加載其狀態。當使用LINQ to SQL對象時,DataContext負責數據庫的回覆,跟蹤對象狀態並將這些更改保存回數據庫。

你會很難在更多的代碼中包裝那些LINQ to SQL類,使它成爲ActiveRecord模式的真正實現(沒有簡單的方法將責任從DataContext中移除)。

+1

我不確定這是否完全正確。實體對象和DataContext共享責任 - DataContext提供了將泛型屬性數據轉換爲SQL的樣板功能,但實體對象提供了對象成員和數據庫之間的映射。此外,實體*的狀態存儲在對象中 - 同樣,DataContext只具有用於協調狀態的泛型功能。 – 2009-06-12 03:52:03

+1

你說得對。但關鍵是,責任仍然是共享的,而不是對象本身處理所有事情(就像您在實現ActiveRecord模式時一樣)。 – 2009-06-12 03:58:07

+0

linq to sql是否給出'每個表的一個類'映射?這將是ActiveRecord的一個特點。這導致遠離其他面向對象模式,如域驅動設計。 – 2009-06-12 04:57:58

2

LINQ to SQL不是Active Record的實現,這意味着實體完全負責管理其自己的持久性(即持久性感知)。 LINQ to SQL實際上是Unit of Work的實現。工作單元意味着某種註冊表或上下文可以隱式或顯式地跟蹤實體的狀態,從而允許實體完全不瞭解其持久性機制(即持久性無知)。

工作單元支持稱爲POCO(普通舊clr對象)的編程風格,它可以幫助您維護separation of concerns並維護principle of single responsibility。當這兩位負責人得到滿足時,您的軟件通常會更容易維護。 Active Record實際上破壞了這兩個主體,導致更加緊密耦合的軟件更難以維護。