混合存儲過程業務邏輯和ORM

Question

我工作的公司開發了一個幾乎完全基於存儲過程的大型應用程序。

我們使用經典的ASP和SQL Server，業務邏輯的主要部分包含在這些存儲過程中。例如，（我知道，這是不好的......）單個存儲過程可以用於不同的目的（插入，更新，刪除，進行一些計算，...）。大多數情況下，存儲過程用於相關表上的操作，但情況並非總是如此。

我們計劃在不久的將來轉移到ASP.NET（WebForms）。

我已經閱讀了很多關於StackOverflow的文章，建議我將業務邏輯移到數據庫之外。 事情是，我試圖說服那些在我們公司作出決定的人，並且我沒有辦法改變他們的想法。

由於我希望能夠使用面向對象編程的優點，我想將表映射到實際的類。 到目前爲止，我的解決方案是使用ORM（Entity Framework 4或nHibernate）來避免手動映射對象（主要用於檢索數據）並使用某種數據訪問層調用現有的存儲過程（用於保存） 。

我想要你的建議。 您認爲這是一個很好的解決方案嗎？有任何想法嗎？

編輯：我應該只使用標準的DataTable/DataRow方法嗎？

Answer 1

在我的意見的

存儲過程是您爲多，原因有很多朋友。我強制在我的項目中執行存儲過程中的所有數據庫操作，並鎖定SQL服務器上的應用程序帳戶，只允許它執行存儲過程（不能直接訪問任何類型的表）。儘管如此，在同一個過程中混合更新/刪除會讓我感受到糟糕的做法（儘管我傾向於在同一過程中合併插入/更新）。

另請注意：當您從ASP移到ASP.NET時，存儲過程中的任何邏輯都不必重新實現，因爲它存在於Web代碼之外。 +100分保持查詢所屬的位置。

這些天常見的「智慧」表明，你應該只使用你的數據庫服務器作爲對象存儲，我堅決不同意。我有幾個項目，經過多年的服務，突然需要與其他用不同語言編寫的應用程序共享數據和邏輯。將大部分數據庫代碼實際存儲在數據庫中以及應用程序代碼之外，這使得項目之間的代碼重複性非常直接且最小化。

將ORM與存儲過程混合起來聽起來像是一個在年輕時減肥和頭髮的好方法。

將現有的應用程序從當前的數據模型切換到ORM，除了從ASP轉移到ASP.NET MVC的複雜性之外，還會爲已經具有挑戰性的任務添加大量變量和失敗點。如果你不能向權力提出令人信服的論點，那麼當一個ORM是一個好主意時，你可能會問自己爲什麼會這樣。

Answer 2

我認爲這是一個很好的解決方案。如果您不仔細檢查觸發器對您的表格數據可能會做什麼，請注意您可能會遇到的副作用。另一方面，對於某些類型的應用程序，我仍然認爲在數據庫端擁有業務邏輯是非常好的解決方案。將它從數據庫中取出並不總是最好的選擇。有很多事情要考慮。

Answer 3

您期望獲得的面向對象編程的優點是什麼？

當人們談論OOP的優點時，他們通常意味着集中商業邏輯或對相關操作和數據進行有意義的抽象。將業務邏輯放入存儲過程會破壞這些抽象並分散業務邏輯。

如果您的團隊打算保留業務邏輯流程，那麼您至少應該考慮以這種方式保持內容：使您的代碼流程化，因此只有一個地方可以查找您的邏輯。

話雖如此，使用ORM將您的數據映射到data transfer objects（沒有任何重要的行爲或邏輯）以便在您的網站中使用是很常見的。 Dino Esposito的Pros and Cons of Data Transfer Objects涵蓋了你的問題 - 只要將你的存儲過程想象成服務層。

Answer 4

這完全取決於業務需求。存儲過程中的多少業務邏輯以及多個存儲過程之間建立業務工作流程的依賴關係很重要。

可擴展性受到很大的影響。當進程等待完成時，依賴邏輯可以阻止CPU使用。對於服務驅動體系結構來說，並行化是非常重要的，其中數據庫需求基本上是讀取緩存以提高性能。爲什麼擊敗一個CPU盒子並阻塞並堵塞工作流程，在哪裏分配？

我認爲這些論據必須考慮到這些因素，而不會在任何年齡段失去頭髮。