Linq-to-sql的查找表

我目前在一家汽車經銷商網站上工作，我一直在研究數據庫中的'Vehicle'模型。我已經廣泛運用與喜歡的事情顏色的FK關係的查找表，品牌，型號等Linq-to-sql的查找表

所以基本版本可能是這樣的：

Vehicle { 
    Id 
    MakeId 
    ModelId 
    ColourId 
    Price 
    Year 
    Odometer 
}

，然後使用一個簡單的2-列查找表，例如Color將具有ColourId列和ColourText列;沒什麼特別的

這很好，但是我發現當你開始使用查找表時，我生成的Linq-to-Sql類變得更加複雜。爲了獲得顏色，我現在必須做一些事情，比如Vehicle.Colour.ColourText。添加新的車輛需要查找所有各種表格以確保值在那裏，等等。所以我真的不希望在我的應用程序代碼的其餘部分傳遞這個Linq-to-Sql模型。

所以我現在的方法實現了幾個方法來將這個linq模型轉換成一個純粹的域模型，它幾乎是一個完全相同的對象，只是用它們的實際文本值（字符串）替換了Id域。這全部包裝在一個存儲庫中，所以應用的其餘部分只知道這些直接的「域」對象，而不是數據訪問對象。如果應用程序需要插入新記錄，我將該域模型傳回存儲庫，然後將其轉換回Linq-to-Sql變體，確保所有查找值實際上都是有效的。

這是個不錯的點子嗎？我覺得在做這種轉換時有點髒，這似乎違背了首先使用Linq-to-Sql的原因之一。然後再次，我想這會更糟地傳遞給應用程序其餘部分的查找等等的對象。這就是爲什麼更成熟的O/RM更廣泛使用？

在L2S上使用域對象也使JSON序列化更容易與AJAX等一起使用。

我想我只是問我採取的方法是否合理？乾杯。

來源

2009-08-19 CapBBeard

你所做的是從LINQ創建低級對象，然後在它們之上構建自己的Business Objects（或View Model）。

這沒什麼不妥：事實上，它可以幫助將應用程序從關係模型中分離出來，並將其更充分地引入Object領域。當人們構建ViewModel以綁定到UI時，您會明確地看到這一點，而ViewModel實際上是通過低級實體加載和保存的。

缺點是編碼更多。好處是您的對象集合實際上更好地反映了您的應用程序用例。我建議繼續探索這條道路。也許這裏一起來幫助你：http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx

來源

2009-08-19 01:45:56 Godeke

Linq-to-sql的查找表

回答

相關問題