切換到LINQ

我在考慮花時間學習和使用LINQ to SQL，但經過多年的最佳實踐建議不要嵌入SQL我很難改變範例。切換到LINQ

爲什麼現在看起來已經接受將查詢嵌入到編譯代碼中？在某些方面，我似乎倒退了一步。

有沒有人在切換到LINQ後修復查詢/編譯/部署週期問題？

我想我仍然可能會等待完成的實體框架。

你覺得呢？

來源

2009-04-30 Chad Grant

+1指出將SQL嵌入編譯後的代碼是非常糟糕的做法！我和你在一起，夥計！ – 2009-04-30 11:29:02

Linq to Sql的優點是它並沒有真正將編譯代碼嵌入到查詢中。 Linq語句意味着您的.Net代碼實際上具有構建嵌入的Sql語句所需的邏輯，而不是原始Sql。

讓.Net代碼直接轉換爲Sql來執行，而不是一長串sprocs和相關文檔，這確實很有意義。 Linq方式更容易維護和改進。

我不認爲我會將現有的項目切換到Linq--它實際上是對整個數據層的替代，它可以改變對該層的所有訪問都完成的方式。除非你從一個非常相似的模型轉換，否則任何潛在收益的成本都會太高。 Linq to Sql的真正實力在於快速創建新的應用程序 - 它允許您快速創建數據層代碼。

來源

2009-04-30 10:13:45 Keith

同意，除了LINQ to Entities現在可能是一個更好的開始（但所有相同的註釋重新嵌入查詢都適用）。 – Richard 2009-04-30 10:16:02

自EF以來，我一直在開發一個大型項目（現在6個月），我很後悔。 EF尚未準備好生產。 Linq2SQL是。 EF由於它現在是一種半支持的數據訪問技術，存在很多缺陷，查詢效率低下，Linq實現不完整，數據綁定缺陷以及客觀和服務模型不佳。拯救自己的痛苦，並使用Linq2SQL這是一個偉大的技術。那麼看看EF vNext有多棒，但在那之前我的繼續工作就是避開它，這太麻煩了。 – 2009-04-30 11:16:43

您需要將LINQ to SQL視爲上面直接編寫SQL的抽象概念。如果你能夠解決這個問題，那麼你已經朝着正確的方向邁出了一步。您還需要放棄一些長期持有的信念，例如編譯的sprocs總是更快，並且SQL帳戶不應具有數據讀取器/寫入器權限。

我發現，只要存在清晰的DAL，並且只是在不影響與消費代碼簽訂的合同的情況下更改實現，就可以逐漸將現有解決方案移至LINQ to SQL。參考列表是一個簡單的候選，因爲它們影響力不大，只讀數據集。如果您已經手動編碼模型化數據庫，則需要保持意識的主要事項是可能存在模糊的類名。由於將LINQ to SQL引入大型企業（自CTP之日起），事後的看法的價值，我會再次心跳。這並不完美，存在問題，但在開發速度和可維護性方面尤其如此。這是一種新的範式，絕對是向前邁出的一步。

來源

2009-04-30 10:28:03

我undertand您的角度來看，這的確看起來有點落後一步的......

其實我可能會引導從LINQ客場SQL和LINQ期待更多的實體，您的實體模型的概念數據模型和我personaly感覺更舒適嵌入查詢再次在我的代碼中的概念模型。實體框架抽象出實際的物理模型。

此鏈接（請原諒這個雙關語）討論LINQ到實體和實體框架：http://msdn.microsoft.com/en-us/library/bb386992.aspx

這是一個有趣的文章discussign這兩種方法的優點和缺點：http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm

編輯另一種思考，如果你不想等到EF，那麼看看NHibernate，你也可以LINQ到那...看到http://www.hookedonlinq.com/LINQToNHibernate.ashx

來源

2009-04-30 10:37:46

理論上，是的。但在實踐中，我真的很猶豫開發基於Entity Framework/Linq-to-Entities的任何生產代碼。 Linq-to-SQL是生產就緒的，EF不是。雖然正如你所說的那樣增加了一個額外的抽象層，但這種抽象的代價是在另一端（db端）出現低效的SQL查詢。 EF vNext - 也許，但陪審團仍然在那一個。我們只需要知道它在發佈時會帶來什麼，但是現在用於EF（成功或失敗仍然是一個未知數）並不是我會推薦的。只是我的2美分... :) – KristoferA 2009-04-30 10:51:41

有一個LINQ to SQL的實現不僅適用於SQL Server數據庫， SQL Server的發展操作員也可以利用這種高效的ORM。我們已經添加了對查詢級LaodWith（）的支持並擴展了錯誤處理。此外，我們計劃支持所有三種繼承模型（TPH，TPT，TPC）和關鍵字段生成。你可以找到支持的數據庫here

來源

2009-05-07 11:43:50 Devart

我不認爲它是在你的代碼中嵌入SQL的名單比在你的代碼中嵌入一個存儲過程的名稱了。無論如何，對Proc的更改往往涉及對代碼的更改。例如，您通常需要添加新的輸入/輸出參數或更新getter/setter方法來引用新列。

它所做的是刪除大量編寫兩倍的代碼以使代碼中的屬性和方法與數據庫中的特效和列對齊。

來源

2010-02-01 22:16:19 misteraidan

回答

相關問題