將SPROCS遷移到LINQ-to-SQL預編譯的動態SQL？

Question

我想將現有的存儲過程轉換爲LINQ-to-SQL預編譯的動態SQL。有誰知道最好的方法來做到這一點？

我提到預編譯，因爲我相信我可以獲得性能提升 - 與SPROC不一樣，但類似，正確嗎？還有LINQ-to-SQL預編譯的動態SQL，我得到強類型的字段等。這些假設是否正確？

此外，它可能不可用，但有沒有辦法將我的存儲過程自動轉換爲LINQ到SQL？

Answer 1

不，我不同意你的假設。

1 /存儲過程將提供至少與LINQ-to-SQL一樣好的（如果不是更好的話）性能。通過轉移到LINQ到SQL，您不會看到任何性能提升

2 /您可以使用現有存儲特效獲取強類型字段。我相信你通過使用DataSets（從內存）得到了這個，但是我確信如果你創建一個LINQ到SQL類，並且簡單地將Stored Procedures拖到設計器上，你會得到它。代碼生成器將爲每個存儲過程創建強類型並正確命名的ReturnObjects。

如果你有現有的存儲過程，那麼我不會打擾他們轉換成LINQ。

Answer 2

將所有存儲過程轉換爲LINQ to SQL將是一項重要工作，具體取決於您擁有多少存儲過程。我會建議，這是我們在這裏所做的是你設置一個日期開始與LINQ to SQL，而不是存儲過程前進。這樣，所有新功能都將使用LINQ to SQL，如果您回到舊功能並添加新功能，而不是將其轉換爲LINQ to SQL。

您還可以將存儲過程導入到LINQ to SQL中，並將它們用作函數。解決這個問題的最佳方式是逐步緩慢地移動一個功能，並最終全部轉換。

至於性能提升，你可能不會馬上看到任何巨大的收益。這將取決於您的存儲過程如何優化？ LINQ to SQL生成相當高效的SQL代碼，但不是在所有情況下，有時您將不得不編寫一些SQL來獲得所需的性能。我發現很多與我一起工作的開發人員並沒有在存儲過程中編寫非常高效的SQL代碼。有時候是因爲時間有限，有時候是因爲他們不知道更好。在這些情況下，LINQ to SQL傾向於更好地執行，因爲SQL生成比開發人員可以自己寫的更加優化。我發現的另一個有趣的觀點是，LINQ to SQL傾向於寫比LINQ to Entities更高效的SQL，只是要記住。

最後，我不知道任何將存儲過程轉換爲LINQ to SQL的工具，但實際轉換不是很困難，LINQ與SQL非常相似。

希望這會有所幫助。