使用存儲過程作爲業務邏輯層

Question

我正在使用的公司正在使用存儲過程（在MsSQL服務器後端）作爲其業務邏輯層。實際的業務邏輯DLL只是調用sProcs並基本上管理用戶界面（事件，數據綁定等）

我認爲設置有問題，儘管我不知道如何向同事解釋。順便說一句，該系統的工作。

我工作場所的「最佳實踐」錯誤嗎？或者我只是在推崇這一點？

Answer 1

GaiusSensei - 只要業務領域能夠應對業務實踐中的地震變化，那麼以這種方式工作就很好。我認爲SP和BLL dll之間的辯論仍然很盛行，毫無疑問，這個主題中雙方都會有很多。然而，從我自己在過去10年一系列項目的經驗，這裏是我的意見支持BLL DLL的方法：包含在BLL

• 邏輯可以 存儲介質和 的「不可知」因此，更靈活地改變 （壽多久出現這種情況是 值得商榷）
• 更細粒度的控制業務 權限在一系列依賴於 數據存儲 應用。我的意思是核心 表的完整性必須是 保持在特定水平 它在業務 應用程序中使用。
• BLL邏輯可封裝在自己的 包含的類別中，該類別可在業務的其他領域和/或項目中重複使用 。這個類甚至可以 寫成一個密封類或 擴展取決於你的目標 「觀衆」
• 單元測試 - 這（在我的經驗 ）是一個黑色的藝術，如果使用 SP的內部。在java/c＃下，這個 是標準的，現在有些人會說 強制性的練習。
• 可維護性。通過保持一個BLL DLL中以及 舉辦接口 情況下，你可以很容易爲 支持開發者來擴展你的 類，而不會破壞現有的 邏輯
• 可移植性。您的BLL（取決於 的語言實現）可以是在各種平臺上託管的 。 同樣， implemetation數據存儲區的注入可以 字面上是從XML文件 任何到MySQL，MSSQL postgres的等 等
• 標準化。數據架構師 可以精確地定義每個數據應該從 數據庫中獲取的數據以及應該如何保存每個項目 （這將會更好地位於DAL dll中）。因此， 進入新開發商的成本以及經驗豐富，對該項目的減少很多 。

這個名單還在繼續，但這些都是我採用BLL方法的頭等PROS。

展望FWD的許多自旋在這一個:)

吉姆

[編輯] - 我也想補充一點，BLL應該也不排放任何UI信息，比其他（如你提到）來傳達事件等。每個UI層（與目標設備 - 瀏覽器/移動設備/工廠有關）應該引用BLL並且與數據一起做它自己的'thang'。我進一步補充說BLL下面是你的DAL層。該層可以被認爲是底層數據存儲的1-1參考。

Answer 2

我們這樣做。

這是因爲我們支持用戶使用預期軟件以外的程序（如SQL Management Studio，osql和Excel）連接到數據庫的場景。

當您直接連接到數據庫不超過數據存儲的數據庫時，您可以將所有內容搞亂，因爲沒有任何規則可以阻止您。這些規則只存在於使用此數據庫的程序內部，如果您不使用該程序，則可以使用I-can-write-to-this-table權限來執行愚蠢的（或有趣的）操作。

當您只有執行存儲過程的權限時，您不能。
我個人認爲這是一個更好的方法。

Answer 3

我要說的是，存儲過程不適合自己的單元測試和重構幾乎與業務層邏輯中說.NET/JAVA。我會盡可能地將邏輯從數據庫中排除出去，主要的異常是DBMS擅長的基於操作的固有操作。

Answer 4

（我加的「主觀」的標籤）

我更喜歡使用存儲過程，除了在小應用程序，我馬上拿出，因爲在存儲過程中插科打諢需要一點額外的時間。

Christopherous 5000：你仍然可以做單元測試與存儲過程

我傾向於這兩個類似的問題的答案一致：

• Business Logic: Database or Application Layer

• Should the data access layer contain business logic?

Answer 5

這聽起來像你的業務層實際上是數據層和應用程序中沒有一個業務層，但我離題...

最佳實踐是被高估，並隨着時間的推移而改變。如果他們在做什麼，他們滿足於此，那麼沒有什麼可以做的。

我不能告訴你有多少項目，我一直在這裏新來的傢伙來到船上，並認爲目前的體系結構需要改變。我自己做了幾次。這不是一個好地方。現狀會與你抗爭到最後。如果你真的想改變現有的系統，建立一些可信度。在3到6個月內開始提出更好的方法來處理一些現有的基礎設施。如果你真的不喜歡當前的架構，那就離開公司。

該應用程序是用最好的意圖書寫的。原始開發人員受到時間，經驗和技術的限制。

像你描述的應用程序的應用程序是成熟的學習機會。注意失敗點，從成功中學習。你會驚訝於你學到的東西。

Answer 6

我認爲存儲過程很好，作爲您的業務邏輯的一部分。我不認爲你需要在一個DLL中擁有整個業務邏輯。但是，如果您有一個管理UI的業務層，我認爲您需要用某種框架將UI管理與業務層分開。分離應該是功能性的，不要將數據嵌入到存儲過程或業務邏輯中，反之亦然。我也認爲，如果你有其他程序，如Excel或報告，通過離散數據源，Web服務或其他方式訪問他們應該進入的數據。

我用它來處理帶有大型機的客戶端服務器系統，在這些系統中，您可以實現三層真正的分離和真正的骨幹不靈活性。現代應用程序需要在實現上更加開放，並且在所有層都有業務規則，特別是驗證。這並不意味着你的設計模型不能分離，只是像'空白或星期幾'這樣的業務規則必須在UI，業務層和數據中實現。

如果你有什麼作品，只是想象如何使用它繼續前進。

Answer 7

這取決於。

這取決於您所稱的業務邏輯。

某些事情需要在數據庫中強制執行 - 尤其是任何其他進程將假設數據庫呈現的性質的東西。

如果數據庫的所有用戶都假定當一個計費方的最後一個後代被停用時，計費方狀態需要改變，那麼這需要在數據庫中執行 - 或者在唯一的SP中執行操作或觸發器的方式，或約束或其他。這是一種事情 - 低層次的業務邏輯，它在業務層面上是非常關鍵的數據完整性邏輯 - 這在數據庫中是可以實現的。

高級業務邏輯不適合數據庫 - 例如，當患者取消最後一次約會並需要重新召回列表時 - 這不是數據完整性問題 - 系統的所有呼叫者都不承擔沒有約會的患者必須在召回清單上。

區別很微妙，這就是爲什麼人們在數據庫中存在「業務」邏輯的困難。我只推薦那些假設數據庫在數據庫周邊向數據庫中的所有用戶提供保護並呈現給數據庫的東西 - 該業務邏輯位於DAL層之下，並且是基本數據庫設計的一部分。我仍然在傳統體系結構中倡導一個高於此值的業務盲DAL和一個真正的BLL。

話雖這麼說，當DAL真的很簡單的SP泵抽取數據庫中的高級業務邏輯時，當然也是可能的，而且當你這樣做時，它不太清楚哪些事情是低級的，這是高層次的（除非你有兩個數據庫，一個建立在另一個之上 - 這不一定是一個可怕的想法）。您已經有效地將您的業務邏輯的一部分寫入了SQL，而不是傳統的客戶端應用程序。

這並不一定意味着您的圖層耦合過緊或者您的架構很糟糕 - 就像任何系統一樣，不同圖層的語言選擇不一定指向架構問題。只有通過查看圖層，您才能確定是否存在架構問題。

Answer 8

如果您的同事想要重用MySQL的業務層，該怎麼辦？你會告訴他這是不可能的，因爲一些業務層駐留在SQL Server中。