從舊數據層來的LINQ to SQL /實體框架

Question

有幾個「應該我選擇了這樣或那樣的」關於SO和谷歌的問題，還有很多比較LINQ2SQL和LINQ2E。我見過的缺點，差異，缺點，優點，侷限性等

我不能說我是專家，但我想知道「你會做什麼」，如果你遇到這種情況和原因。

我要的東西添加到「老」 2.0應用程序，最近已遷移到3.5（它種編出來的方塊，在這裏和那裏的一些警告）。由於我不得不添加新的東西，我想開始使用LINQ（2SQL或實體）。

我以前和Linq2SQL一起工作過，我喜歡它是一個快速，易於使用的解決方案...... 如果你不想做太奇怪的事情。如果你來自舊的「記錄集」，表格之間的自然1..1關係是天賜之物。同樣不錯的是，根據您想要使用的表格集合，可以擁有不同的數據上下文。

隨着事物和新功能的數量增長，我已經開始考慮嘗試實體框架，而不是LINQ2SQL的可能性。我不喜歡後者是無法處理Many2Many關係，而不訴諸於hack。

這就是實體框架的用武之地。但，你不能有多個「小模特」像你LINQ2SQL和「datacontexts」這樣做，除非你犧牲some的東西，有些東西other。

數據庫有218臺，現在，它並沒有顯着增長。不時有新桌子，但我們並不是每天談論10桌。我想說，在接下來的一年裏，我們將有一個「困難時期」達到250張桌子。

有是許多2個多關係，有些與PK /只PK和一些與骨料（其中實體框架不magically handle，但它可以對付他們。這就是爲什麼我不希望的原因從LINQ2SQL開始，除非hack是「OK」並且是可接受的方法。

你會做什麼？妥協N..N關係（即使存在黑客攻擊，它也不會像優雅， 「作爲一個集成的解決方案），並與Linq2SQL和」有很多小的數據環境，你創建和銷燬「哲學，或者，另一方面，與實體框架繼續，有一個巨大的數據模型與所有表或關係，並從那裏開始？ 即使創建多個模型存在缺點（請參閱此處的鏈接），並讓一個巨型模型具有缺點。

也有關於微軟「放棄」Linq2SQL的非官方評論（我懷疑，但你永遠不知道）。我們的數據庫是MSSQL，我不會很快看到變化。

在這個問題上的任何經驗將不勝感激。

Answer 1

我正在處理Linq2SQL中的多對多關係。

看到here爲neato擴展方法來解決你的痛苦！

就個人而言，我覺得用一個整體模式是最容易處理的。

Answer 2

我會在你的情況下做什麼？我會使用NHibernate和Castle Active Record。

爲什麼？因爲該解決方案爲「真實世界」場景提供了最好的支持，尤其是您提到的場景。 NHibernate與你的項目進行比例縮放，並不限制你。它基本上是免費的。 NHibernate是一個非常成熟，經過充分測試的解決方案。

你不提NHibernate的，你正在尋找到的東西，所以我不知道什麼並不在這方面吸引你（好像你已經閱讀不夠，你會遇到那個選項）。

LinqToSql /的EntityFramework不提供一大堆，你也無法與NHibernate得到。