asp.net站點的修補方法

Question

我正在處理.net 3.5中的一個新項目。

當前客戶端正在使用存儲過程，我們真的很想使用LINQ to SQL。他們使用存儲過程的主要原因是因爲他們認爲他們更容易更新，所以他們不使用任何特殊的權限，或者我可以看到證明使用LINQ to SQL存儲過程只是他們不想改變。

我想，如果我能向他們展示一個解決方案，他們可以輕鬆地將更改部署到LINQ to SQL，他們可能更願意改變主意。

因此，我很好奇與一個asp.net項目（而不是mvc）如何去更新在構建過程中創建的各種程序集。

舉例來說，我所有的LINQ代碼都在System.DataAccess項目中，並且被部署到生產環境中，然後一個prod bug被LINQ識別。僅部署已更改的DataAccess項目（或者更確切地說，自從部署之後發生重大變化的任何項目）是多麼困難。

有一件事我不確定這將有助於這種情況，即每次構建時，內部版本號都會在所有項目中得到更新，無論是否存在實際更改，只需查看版本號的項目不足以確定需要重新部署的項目。

我甚至不確定是否可以修改一個版本，以便只更改已更新的項目版本？

所以基本上我只是好奇於各種修補過程和優點和缺點（即需要iis重置等）。

乾杯

Answer 1

兩者都有優點和缺點。

SQL存儲過程快速高效。您可以使用Stored proc來執行繁重的SQL操作，該操作的執行速度將快於您在代碼中執行的任何操作，但這是另一層。

當發生更改時，LINQ不需要進行多少維護工作。編碼很容易。

對於任何方法，您都不需要重置IIS。更新每個版本的彙編文件版本是一種很好的做法 - 只有在該程序集中更改代碼時纔是如此。僅僅因爲升級版本會很麻煩而且不需要。

這兩個補丁都很容易。我發現LINQ更容易恕我直言。如果表格結構發生變化，我不需要修改存儲過程和使用這些存儲過程的函數。這是一個快速的變更腳本，您的DBML應該已經更新，因爲您已經使用新版本進行了測試，那麼這是一個部署。

我總是在同一個程序集中有我的LINQ和部分數據類，所以它是一個簡單的DDL版本。

Answer 2

SQL存儲過程和LINQ-SQL不是互斥的。

通常對於複雜，貪婪和資源密集型操作，您仍然使用SQL存儲過程（例如，依賴複雜子查詢/數據庫邏輯的INSERT操作）並將它們拖到LINQ-SQL畫布上。

就修補而言 - 只要簽名不改變（params/return類型），就可以直接在SQL Server中修補這些存儲過程，並且不需要重新編譯LINQ-SQL類。

從某些程序集更新版本號 - 不理想。得到非常混亂，甚至可能導致問題（強命名）。

您應該將所有DB邏輯/ LINQ/CRUD操作放在一個程序集（DAL）中。

如果你真的想要隔離LINQ邏輯並啓用這些程序集的獨立部署 - 也許你應該考慮將你的解決方案劃分到web/app服務器中？即擁有您的LINQ DAL Assembly和類似外觀的Assembly，它們在應用程序服務器上公開這些操作，然後在單獨的Web服務器上公開您的網站。

根據您的體系結構，您可以使用ASMX/WCF/.NET Remoting在Web /應用程序服務器之間調用調用。 （WCF不起作用跨域）。如上所述，如果您已經正確完成了LINQ-SQL類（簡單的LINQ CRUD操作，視圖，存儲過程的良好組合），那麼您仍然可以輕鬆修補存儲過程而不影響您的應用程序。