'將業務邏輯移至應用層'可以提高性能嗎？

Question

在我目前的項目中，業務邏輯是在存儲過程（其中1000多個）中實現的，現在他們希望隨着業務的增長擴展業務邏輯。架構師決定將業務邏輯轉移到應用層（.net）以提高性能和可伸縮性。但他們不重新設計/重寫任何東西。簡而言之，從SP觸發的相同SQL查詢將使用ADO.Net從.net函數中觸發。這怎麼能產生任何表現？

據我所知，當我們需要數據庫獨立性時，我們需要將業務邏輯轉移到應用程序層，或者在OOP語言中可以比RDBMS引擎更好地實現一些業務邏輯（例如遍歷層次結構或一些圖像處理等）。在其他情況下，如果沒有複雜的業務邏輯來實現，我認爲最好是將業務邏輯保存在數據庫本身中，至少可以避免應用程序層和數據庫之間的網絡延遲。

請讓我知道您的意見。我是一位開發人員，稍微猶豫地看着一些架構決策，請原諒我對這個主題的無知。

Answer 1

如果您的業務邏輯仍然在SQL語句中，那麼數據庫將會像以前一樣完成更多的工作，並且不會獲得更好的性能。 （如果不能像存儲過程一樣有效地緩存查詢計劃，則可能需要更多的工作）

爲了獲得更好的性能，您需要將某些工作移至應用程序層，例如，您是否可以緩存應用程序服務器，並執行查找或驗證檢查而不觸及數據庫？

Answer 2

像這樣的架構論據通常需要考慮許多交易點，考慮孤立的性能，或者考慮只考慮性能的一個方面，比如響應時間往往會錯過更大的圖景。

在執行數據庫層中的邏輯和將數據傳送回應用層和在那裏處理數據之間存在一定的折衷。數據運輸成本與處理成本。正如您所指出的，業務邏輯的成本和複雜性將是一個重要因素，要發貨的數據量將是另一個重要因素。

可以想象，如果數據庫層變得繁忙，即使單個響應時間增加，將處理卸載到另一層可能允許更大的總吞吐量。然後，我們可以擴展應用程序層以處理一些額外的負載。你現在會說性能已經得到改善（整體吞吐量增加）或惡化（響應時間增加）。

現在考慮應用層是否可能實現有趣的緩存策略。也許我們獲得了非常大的性能勝利 - 對於某些請求，數據庫根本沒有任何負載！

Answer 3

我認爲這些決定不應該使用建築教條來證明。數據會更有意義。

像「所有業務邏輯屬於存儲過程」或「所有應該位於中間層」的語句都傾向於由知識僅限於數據庫或對象的人員完成。更好地結合兩者當你判斷，並根據測量做到這一點。例如，如果您的某個過程正在處理大量數據並返回一些結果，則有一個說法說它應該保留在數據庫中。將中間層的數百萬行帶入內存中，對它們進行處理，然後用另一次往返更新數據庫是毫無意義的。

另一個考慮因素是數據庫是否在應用程序之間共享。如果是這樣，邏輯應該留在數據庫中，這樣所有人都可以使用它。

中間層傾向於來來去去，但數據永遠存在。

我自己是一個對象，但我會輕輕一點。

這是一個複雜的問題。我不認爲黑色和白色的聲明在任何情況下都適用。

Answer 4

就像其他人已經說過的那樣，這取決於很多因素。但是從你的問題來看，似乎架構師提議將存儲過程從DB內部移動到應用程序內部的動態SQL。這聽起來很可疑。 SQL是一種面向集合的語言和業務邏輯，需要大量數據記錄的按摩在SQL中會更好。認爲複雜的搜索和報告類型功能。另一方面，使用相應的業務規則驗證的訂單項編輯在編程語言中完成得更好。在應用層中緩存變化緩慢的數據是另一個優勢。如果您有專門的中間層服務，充當所有數據的網關，這將更好。如果數據直接在不同的應用程序之間共享，那麼存儲過程可能是一個好主意。 您還必須考慮組織中SQL人才與編程人才的可用性/經驗。 這個問題真的沒有一般的答案。