1. 首頁
  2. 問答
  3. Linq to SQL有什麼問題？

Linq to SQL有什麼問題？

2008-10-02 76 views
9

Linq to SQL有什麼問題？Linq to SQL有什麼問題？

或者 - Linq to SQL會如何使它不適合新項目或現有項目？我想知道爲什麼你會爲而不是爲特定項目選擇Linq to SQL - 包括哪些項目參數使其不適用。

來源

2008-10-02 Erik Forbes

回答

16

它對數據庫模式的變化不太適應。您必須重建dbml層並重新生成數據上下文。

就像任何ORM（我沒有深入討論它是否是ORM），你必須知道生成了什麼SQL，以及如何影響你的調用。

插件沒有批處理，因此性能可能很高。

它被已停用支持實體框架

儘管它使用的是供應商模式，將允許服務提供商爲其他DBMS平臺上建立的事實，只有SQL Server的支持。

[編輯 @ AugustLights - 以我的經驗：]延遲加載可以需要一些黑客獲得工作的。

話雖這麼說，我認爲，如果正確使用

來源

2008-10-02 23:57:06 johnc

+4

如果你不使用設計師或代碼gen，那麼呢？映射可以通過屬性或XML配置完成 - 在這種情況下，使用Linq to SQL響應模式更改與其他ORM類似，不是嗎？ – 2008-10-02 23:58:56

+1

相信我Erik你不想手動做映射。有太多屬性需要設置。哦，LINQ to SQL設計器還有一件事是非常麻煩的。 – azamsharp 2008-10-02 23:59:57

+0

非常真實，但是典型的LINQ to SQL用戶通常不會在XML中發生黑客攻擊，但是事實並非如此，在LINQ 2 SQL和EF中都存在限制條件的設計師經驗 – johnc 2008-10-03 00:00:10

1

那麼，我已經開發了一些使用LINQ to SQL的應用程序。我發現的一個主要問題是必須對應用程序進行分層。在LINQ to SQL中，實體類與數據訪問代碼非常緊密地聯繫在一起。此外，DataContext也存在一些問題，這意味着您可以使用DataContext對象來檢索項目，但不能將項目（對象）轉移到另一個DataContext（至少不容易）。

如果您不關心如何正確分層應用程序，以及如果您只想以快速方式創建應用程序（也稱爲RAPID應用程序開發），那麼LINQ to SQL將很有用。

來源

2008-10-02 23:51:57 azamsharp

+0

它沒有提供將對象從一個DC傳輸到另一個DC所需的所有內容。但是，可以輕鬆添加 - 請參閱本文末尾的「LinqSync」類：http://blog.huagati.com/res/index.php/2008/06/23/application-architecture-part-2 -data-access-layer-dynamic-linq/ – KristoferA 2008-10-06 05:09:54

+0

我關心'正確分層我的應用程序'，我仍然喜歡linq-to-sql。 – liammclennan 2008-12-23 02:29:18

1

很多的優勢，這是非常方便的LINQ到SQL來自理應能夠構建數據的查詢就在你的代碼隱藏基於來自你的dbml的強類型的可查詢/可枚舉的數據對象（它扮演非常有限的DAL角色）。因此，正如已經提到的那樣，其結果是它鼓勵你有點在你的應用程序之外在強烈定義和分離的層或層之外進行遊戲。
爲了對抗這一點，它應該意味着你應該能夠消除你寫入數據庫存儲過程的大部分或全部業務邏輯，所以至少你只需要去處理與之相關的代碼數據來改變不影響模式的業務規則......但是，當你意識到使用外部連接編寫一個帶有分組聚合的查詢是多麼複雜時，至少當你第一次使用分組時，會發生一些變化。所以你會試圖在你知道的SQL中編寫sprocs，這樣做很簡單並且擅長做這些事情，而不是花費額外的時間試圖弄清楚LINQ語法在它要轉換它時做同樣的事情到醜陋的SQL代碼無論如何...
有人說，我真的很喜歡LINQ，當我開始忽視這種「查詢語法更易於閱讀」的情緒，我已經看到浮動和切換到方法語法。從未回頭。

來源

2008-10-03 00:05:13 Grank

3

因爲你沒有使用3.5 ...是一個有效的答案嗎？！？！？

來源

2008-10-03 00:18:57 RhysC

9

對於需要使用SQL Server以外的數據庫項目：

1）你是鎖定在使用SQL Server

對於複雜的實體間關係和/或關係是變化的項目隨時間推移逐漸：

2）你被鎖定在1對1的映射表上課

對於必須使用的.NET

.x版項目

3）不會與.NET 1.x一起工作

來源

2008-10-03 02:25:30 hurst

-2

在over here之前詢問過此問題。但是，實質上，LINQ to SQL會在您的數據庫中生成次優執行計劃。對於您搜索的每個不同長度的參數，它都會強制創建不同的執行計劃。這最終會阻塞正在用於緩存執行計劃的數據庫中的內存，並且您將開始過期較舊的查詢，這些查詢在再次出現時需要重新編譯。

正如我在提到的問題中提到的那樣，這是你想要完成的事情。如果您願意交易執行速度以提高開發速度，LINQ to SQL可能是一個不錯的選擇。如果您擔心執行速度，還有其他可用的ORM/DAL /解決方案可能需要更長時間才能使用，但會爲您提供針對架構更改和更高性能解決方案的未來驗證，但需要花費額外的開發費用。

來源

2008-10-03 15:20:44

4
  • 沒有辦法在數據上下文中混合n匹配延遲加載/加載。
  • 真正的堅持無知是非常困難的。
  • 映射選項是有限的。例如，沒有多對多的關係。
  • 使用模式更改來重新映射映射是很痛苦的。

儘管以上所有我認爲linq-to-sql是許多項目的絕佳選擇。

來源

2008-10-06 04:01:48 liammclennan

1

我將標籤作爲技術性「showstopper」的唯一方法是如果您想使用其他RDBMS而不是SQL Server。 （雖然它可以解決 - 見馬特沃倫的博客@http://blogs.msdn.com/mattwar/）

除此之外，有一些優點和缺點已列在您的問題的以前的答案。然而，到目前爲止所提到的所有消極因素都有解決方法，所以它們並不是真正的炫目者。

非技術[潛力]攪局者是MSFT會放棄它支持EF的風險...更多，在這裏：http://oakleafblog.blogspot.com/2008/05/is-adonet-team-abandoning-linq-to-sql.html

雖然（在我看來）EF的當前狀態足以讓他們繼續在L2S上工作。所以，讓我們希望他們做...

來源

2008-10-06 05:21:04 KristoferA

1

真正的ORM應該將業務實體的設計與持久性介質分開。這樣你可以分別重構其中一個，只需要維護兩者之間的映射。這減少了您需要爲數據庫更改而維護的應用程序邏輯代碼的數量。

要使用Linq-to-SQL來實現這種持久性不可知的方法，您必須在DTO上使用它生成的類並維護DTO和實體之間的映射邏輯。

採用這種方法（如NHibernate）有很多更好的ORM，大大減少了對DTO的需求。

來源

2009-04-14 19:48:23

相關問題

 相關問題