我不得不爲我的大學開發系統，其中包括跟蹤幾乎所有的數據（講座，講師，助教，學生等）。 我的數據庫有30張桌子，它很漂亮複雜。 我用EF和linq來解決連接數據庫並從中查詢。 但是我越走越多，我的查詢變得越來越難寫，更不用說維護。 以下是一個查詢的示例：http://pastebin.com/Za1cYMPaLinq，實體框架及其用法
這是非常混亂，你可以看到。
那麼，我濫用LINQ（LINQ可以解決這個問題，但以不同的方式）或LINQ只是不是像這樣的更復雜的系統？
這是一般性問題，不是解決特定問題的方法之一。
一般來說，通過將您的重複代碼抽象爲可重複使用，易於維護的組件可以減少複雜性。
你的具體情況，可以通過實施Repository和Specification模式使你的代碼更一致，更易於閱讀，並且易於維護可以降低複雜性。
Huy Nhuyen提供了非常有用的一系列文章，解釋了存儲庫模式，規範模式以及如何將它們與實體框架有效結合以獲得更好的代碼。這些都可以在：
如果用原生SQL編寫，您認爲查詢會更好還是更易於維護？在這種情況下，您可以隱藏存儲過程中的查詢。一旦你進入高級查詢，它總是混亂。通過將子查詢隱藏到數據庫視圖或EF查詢視圖中，可以減少一些複雜性。但是，如果您已經高度規範化了OLTP數據庫，並且您需要執行復雜的報告/分析/數據挖掘查詢，那麼它總是會很大且難以維護。這就是爲什麼OLAP系統存在的原因（我沒有檢查你的查詢的內容 - 只是長度，所以不要把它作爲構建OLAP Cube的原因）。
更重要的是查詢的性能...
我想問問你關於LINQ綜合性能。 linq比一些原生sql慢多少？ – Vajda 2011-06-06 20:08:20
@Vajda，一些性能測試的結果發佈在[本博客文章]（http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html） – smartcaveman 2011-06-06 20:13:05
@smartcaveman Woow，linq to sql對於linq到實體的差異並不是很慢。 – Vajda 2011-06-06 20:18:35
Ooof，這是非常討厭的。
你應該考慮一下你的數據庫設計。我相信擁有如此多的表格會導致您的查詢過於複雜。我放置好的一組視圖（或存儲過程）可以簡化查詢邏輯。但是這不會簡化整個系統，因爲在某些時候你必須連接所有這些表。
-1，是的，它很醜。但絕對不需要使用存儲過程。 OP的問題是過度的複雜性和維護難度。從長遠來看，增加應用程序的最小可維護部分的複雜性並不會對此有所幫助。有一個更好的方法。我沒有使用視圖的問題。 – smartcaveman 2011-06-06 20:11:50
@smartcaveman實際上很適合你使用存儲過程。不一定隱藏複雜性，但保護性能。這現在已經很醜陋了，但看看它在SQL profiler中生成的內容然後分析該查詢 – BritishDeveloper 2011-06-06 20:38:32
@smartcaveman您注意到您對Stored Procedures的攻擊。但是，您認爲SQL層最不可維護的假設僅僅是一種意見，僅此而已。一個複雜的系統是一個複雜的系統。在不改變業務需求的情況下，您可以做的任何事情都可以改變這一點 – Jeff 2011-06-06 21:01:18
不知道我在這裏遵循你的邏輯。我認爲複雜性來自數據庫設計。將這些查詢中的一部分移入視圖（或存儲過程）可以幫助簡化存儲庫層。另外，我不確定我是否同意你的假設，即使用Repository和Specification模式可以降低複雜性並提高可維護性。如果有的話，它會將這些擔憂轉移到架構的不同層面。 – Jeff 2011-06-06 20:56:56
@Jeff，如果他的老闆決定將數據庫移動到Oracle或文檔數據庫，會發生什麼？然後，所有內容都需要重新編碼，因爲業務邏輯已被移至SQL數據庫，該數據庫特定於該特定實施。你是正確的，因爲它把問題轉移到了不同的層次，但是由於OP討論LINQ，我不得不假定他是一個交易程序員，而不是數據庫管理員（是的，這些常常是重疊的，但並不總是）。在這種情況下，似乎維護代碼比數據庫更容易。 – smartcaveman 2011-06-06 20:59:20
那個論點是完整的b.s.除非你爲一家軟件公司工作。我一直存在很長時間才知道決策並非如此。讓自己遠離未來可能發生或可能不會發生的事情，只會增加複雜性。 – Jeff 2011-06-06 21:03:05