LINQ to SQL體系結構。什麼是最好的？

這個問題是一個游泳池。我們試圖在使用像LINQ to SQL這樣的ORM時確定最好的構架。我們正在定義的結構適用於其他應用程序通過直接引用DLL或通過web服務訪問的框架。我們有.NET應用程序和PHP應用程序。LINQ to SQL體系結構。什麼是最好的？

的可能性是：

多個數據上下文：Separting數據庫納入工作單位，併爲每一個獨立的環境中。

優點：

使用易
類將被分成不同的命名空間
較小的領域，以保持

缺點：

對象必須如果重複10相關，建立維護地獄
對象不能上下文之間傳遞，創造了在數據庫

單數據的背景中另一個命中的需求：所有表，視圖，存儲過程，駐留在同一個巨大的背景下。

優點：

沒有重複
關係是易於管理，basicaly的LINQ照顧它。
性能更好，數據庫命中率更低。

缺點：

的所有表都在同一個命名空間，代碼完成變成堅果
沒有最好的設計（至少在VS2008）
不能在什麼選擇保存和不保存。全部保存或刪除全部模式。

這是我想到的東西，所以如果有任何其他利弊，請告訴我，我會將他們包括在帖子中。也選擇你最好的一個。

感謝所有

來源

2009-06-26 Oakcool

此外，EF - 但高度相關：http://stackoverflow.com/questions/1028739/should-i-create-a-ado-net-entity-data-model- for each-table-or-one-for-my-whole – 2009-06-26 18:36:30

我明白你的疑惑。當我開始使用LinqToSql時，我也一樣。爲了幫助我找到更好的方式，我開始創建一個個人項目，在那裏我可以測試所有方法，而不必擔心和沒有先入之見。

在本練習中，我發現唯一的一種上下文方法是最有用的。此解決方案似乎更易於維護，如果您需要重新創建域，則只能在一個項目中管理一個文件。

我在練習中意識到的其他方面是直接使用LinqToSql在組織方面效率不高。如果你有一個團隊將執行開發而不是隻有一個人的項目，你應該從他們那裏「屏蔽」LinqToSql。應該有一個「警長」來處理這個域，你也應該使用一些抽象機制來保護模型不被濫用（我實現了一個Repository模式，它運行良好，但你可以找到不同的方法）。

我也遇到了在域內創建一些邏輯組的問題。那麼我所做的就是使用一些DDD（域驅動設計）技術來創建所謂的聚合。聚合是在一個域內的實體的邏輯排列，在這個域中你有一個根實體（作爲聚合器工作）和其他幾個與它們相關的衛星實體。你可以這樣做，在LinqToSql域中創建一些新的實體。這些新實體將與數據庫斷開連接，並將作爲聚合器工作。這種方法將使您能夠在您的域內創建「子域」並幫助您獲得更好的設計。

最後，我意識到使用LinqToSql的最佳方式是將上下文看作簡單的DAL。通過一些擴展（我們可以使用T4來幫助我們創建代碼）重用它的域，其中實體被轉換爲DTO（數據傳輸對象）以將數據展示給其他層。

我發佈（它尚未完成），我的運動在我的博客中採取的步驟：http://developmentnirvana.blogspot.com/

來源

2009-06-27 14:53:35 GRGodoi

在我看來，數據上下文隱藏正視後面的倉庫接口 - 使我們能夠交換的實現，如果我們想（LINQ到SQL/EF/NHibernate的/ LLBLGEN /等）。這樣，數據上下文（多個）的細節是很大程度上一個實現細節。只要經過單元測試;-p

巨大的很少是個好主意;微小的很少有用......我傾向於向下突破系統正進入相關的塊（通常涉及到不同的存儲庫接口），並在該水平想到它。我在這裏有一些其他的想法：Pragmatic LINQ - 雖然我很樂意推遲從Frans等的任何智慧。

來源

2009-06-26 18:33:16

，需要考慮如何使用LINQ to SQL的兩兩件事：

雖然這是微軟表示未來發展的重點將是實體框架，而不是LINQ to SQL
LINQ to SQL將您直接綁定到數據庫結構。如果你使用Entity Framework，你將能夠以獨立於你的數據庫實現的方式來設計你的實體。例如，如果您決定將一個實體分成兩個表格，您的呼叫者將不需要知道。

來源

2009-06-27 14:58:01

聲音像L2S並沒有死：http://herdingcode.com/?p=187 – 2009-06-27 15:01:33

所以一年左右下的多個方面的發展之後，我才知道，是不使用多個上下文是一個好主意，當你有表確實應該存在2個或更多的上下文的問題到達時，通常多對多的關係。會發生的情況是中間只能插入一條記錄，而其他兩個表的記錄已插入，因此如果您使用的L2S與您在其他事務中使用的一樣，那麼該記錄將首先創建，FK等於0 （零），這是無效的（參照完整性），這會導致錯誤。這是我發現的不方便之一，但如果需要，我可以列出更多。現在我正在使用的解決方案是創建一個「調度程序」，這個傢伙負責等待某些條件得到滿足（父母都有一個有效的ID，不同於0（零）），然後插入，這是完成的非常普遍地允許儘可能多的專業化（我有6個上下文），並且它使用PropertyChanged事件來通知調度程序的更改。

因此，在這篇文章中最重要的是，使用一個單一的上下文，如果你不喜歡頭痛（我根本沒有）。然後，儘管有人會問，但爲什麼我繼續使用多種環境，好吧，讓我們說這是一個決定，它來自我的上方，而且我無力回擊。（所有雖然我真的努力，很難）

來源

2010-11-04 04:56:01 Oakcool

LINQ to SQL體系結構。什麼是最好的？

回答

相關問題