爲什麼要將業務邏輯分爲三層？

Question

我剛剛繼承了一個基於網絡的旅行請求系統來支持和維護。我可以 - 或多或少 - 遵循這一切的邏輯，但我無法弄清楚爲什麼做出某些設計決定，我想知道你是否可以提供幫助。例如，我已經發現了「Unobtrusive Javascript」，所以它可能是我以前沒有讀過的策略。

例如。根據大約8種不同的因素，每個請求都需要發送電子郵件給四種類型的經理之一來授權請求​​以及發送給人們的其他電子郵件，僅供參考。

• 客戶端JavaScript跟蹤哪些經理類型需要電子郵件的請求時，這樣等級的人可以選擇接收電子郵件。
• 頁面背後的代碼播放不起作用，但僅保存是否需要將電子郵件發送到四種管理器類型中的每一種以及所選的ID。不是要發送哪種類型的電子郵件。
• 最後，所有的郵件發送都是在Oracle Sproc中完成的，它再次按照哪個順序重新計算要發送的所有電子郵件，並將哪些電子郵件僅作爲信息提供給誰，以及哪些電子郵件僅作爲信息請求授權。

這似乎有點過於複雜。是否有任何理由（除了將數據庫請求保持在最低限度）所有的電子郵件邏輯，創建和發送都應該在一個存儲過程中，而不是放在頁面的代碼隱藏之中？爲什麼在三層重複相同的邏輯三次？

思想歡迎。

Answer 1

「爲什麼在三層重複相同的邏輯三次？」

有沒有好的原因。有很多不好的理由。你可以做一些軟件考古學來猜測造成這種情況的原因是什麼。有時候可以幫助您瞭解爲什麼會造成混亂 - 例如，建築師可能仍然會產生一些影響力，並會扼殺您的努力。

不好的原因包括DBA堅持所有業務邏輯屬於數據庫，無論應用程序變得多麼無用。或者網頁設計師堅持所有邏輯儘可能靠近用戶（即Javascript），無論頁面變得多大。

「是否有任何理由（除了將數據庫的請求保持在最低限度）所有的電子郵件邏輯，創建和發送都應該在一個sproc中，而不是在頁面的代碼隱藏中？

邏輯應該在一個地方，這很清楚。存儲過程是否正確？這是有爭議的。請參閱Where are the Business Rules in MVC,Are the days of the stored procedure numbered?，Business Logic: Database or Application Layer等問題。

業務邏輯屬於單獨的層，獨立於表示和獨立於持久性。

Answer 2

你當然不想在所有三層重複相同的邏輯。但是，數據庫與UI邏輯的良好分離始終是首選。舉個例子，把它放在一個層面上是不可測試的。請參閱Separation of Concerns (SoC) for more on that

Answer 3

好，

我想說的業務邏輯是重複了三個層次「可以」是良好的性能和更好的「用戶體驗」（Web和/或WinForm的）。

示例：假設一個業務規則，說：人的FirstName必須是2至100個字符之間。

• 在數據庫中，該字段可能是最大100個字符的字符串（varchar/nvarchar）。 （在某種意義上，你只要把數據庫中的業務規則）

• 在DB層，你可以「截斷」字符串超過100個字符。

• 應用層絕對應該有這樣的檢查，當然，有關無疑。

並且在用戶界面中，您想要爲用戶提供自動反饋。

沒有理由強制用戶在返回錯誤之前提交該字符串太長！

其他例子：密碼+確認密碼必須匹配......嗯，是有意義的有一個更好的用戶體驗的UI進行檢查，但你不應該忽視其上的應用程序層此檢查的必要性。

所以UI必須瞭解一定的業務規則，以提供反饋的用戶正在編輯的值。

有與「傳播業務邏輯的地方是有道理的」之間「必須分散經營邏輯」的差異。

最後，「業務規則」和「驗證規則」之間有一條細線。驗證規則在UI中是有意義的。