看完這篇文章(business logic database or application layer）我還沒有足夠的理由去對抗「數據庫中的業務邏輯」主題。在哪裏放置業務邏輯，AppLayer或DataLayer？
在我目前的工作中，有很多db事務（實際上）和所有那些蹩腳的代碼很難維護，存儲過程中有很多重複，所以如果你想在表中改變一個值位，你需要找到所有這些程序並將它們改爲你想要的。如果您需要更改一些桌面設計，也會發生同樣的情況。
所有當前的開發人員都非常瞭解SQL，但他們仍然不是任何DATABASE中的專家（8位開發人員）。
目前我們正計劃將整個核心遷移到新版本（包括數據庫設計）。我需要一些例子的：
應用程序語言：Java的
數據庫：Oracle11g的
應用程序將有服務，擔任HTTP網頁和Web服務。
蹩腳的代碼確實難以維護。這是糟糕的代碼的本質 - 而不是它所在的位置。轉向「前端糟糕的代碼」解決方案並不是真正的解決方案。
如果您認爲數據庫結構變化不會影響在前端編碼的業務邏輯...... ummm - 邏輯規定不同。
我認爲有些東西在前端處理得很好，有些東西在後端處理得更好。我認爲，在業務對象級別運行的正確的PL/SQL API設計可以通過將結構變化問題與其他層隔離來緩解結構變化問題。
但是，如果有任何想法支持其他數據庫，那麼這也是一個有問題的想法，因爲不是每個數據庫都支持相同的構造。
至於業務邏輯所屬的地方 - 這可能完全取決於您的應用程序，事實上，出於性能方面的原因，您可能會發現在多層中具有某些方面是有利的。當然，這可能會導致維護問題，但這一切都成爲交付項目或產品所必需的權衡的一部分。
但是肯定沒有一個嚴格的普遍答案。
首先，如果您希望能夠遷移到不同的數據庫品牌，則不應該在存儲過程中擁有業務邏輯。
此外，對於複雜領域，使用OO模型對Java進行建模比在DB方面更自然。 OO很適合表達抽象和它們之間的關係。
該主題的規範書是Domain Driven Design。
留在數據庫方面的原因可能是性能。如果您的業務數據量很大，則可能效率不夠，無法在應用程序中檢索和操作它。批處理尤其如此。
你讀過這些AskTom主題嗎？
他們是很好的閱讀和充分的湯姆·凱特大智慧。唯一的麻煩是他們不支持你想要的答案 - 他們支持相反的觀點！
希望Tom Kyte不會建議Oracle/PLSQL爲最佳解決方案，這是非常天真的想法。 – 2015-11-25 02:17:51
與數據庫中的業務邏輯的問題是
的好處是
我曾經爲一家擁有數據庫中所有邏輯的保險公司工作，這很不錯，但非常昂貴。我認爲針對你的問題的任何回答都將是非常抽象的，因爲要做出這樣的大型架構決策需要考慮許多要點。
你從哪裏得到了7.5萬美元？我希望你不支付EE列表價格（47.5K）和使用16個單核心處理器。 :) – 2011-03-03 00:15:52
如果您需要擴展，您需要EE版本，具有真正的應用程序羣集+支持。這是每個處理器80萬美元，加上其他額外功能。 – Augusto 2011-03-03 09:43:15
數據層中的業務邏輯通常被認爲是邪惡的，原因有幾個，我會試着堅持一般的原則。
你不能幹淨單元測試：
一個單元測試的總體思路是，不僅告訴你有問題，但也說不出哪裏出了問題。如果您的BL處於數據層，並且您的BL測試不起作用，則無法確定問題出在您的邏輯還是數據中。這導致更長的調試時間。
成株和嘲笑整個層：
一個具有將被磕碰整個層的分層結構的主要優點。因此，當您使用存根DAO層時，您的邏輯可以單獨演變（也許由單獨的團隊開發），因此您不擔心如何以及從哪裏獲取數據。這使您可以自由地開發自己的邏輯，而無需擔心域模型甚至尚未完成。
層級：
如果你的層分離乾淨的多（多！），更容易讓他們在不同的物理實例的工作（在不同服務器上的實例）。因此，舉例來說，你可以有幾臺服務器來擴展你的數據層（這是非常罕見的AFAIK）。顯然，如果你的邏輯在那裏會更難（如果可能的話）。
+1單元測試的好處。 – 2011-03-02 16:34:09
「數據層」和「存儲過程」有所不同。 「數據層」之上的存儲過程中有單獨的處理層是完全可能的。 – 2011-03-02 17:10:40
據我瞭解這個問題。在給定的應用程序中，「數據層」是存儲過程，其中也存在一些業務邏輯。 – Simeon 2011-03-02 17:13:05
爲什麼數據庫中的業務邏輯有時候是EVIL？ 您必須完成每個供應商的每個更新，如果您想要將支持從一個供應商轉移到其他供應商，則必定會遇到麻煩。如帖子中提到的那樣昂貴。
數據庫中的業務邏輯是多少和什麼時候是一個好習慣？ 通過存儲過程來更新或刪除外鍵或相關行的邏輯應該沒有問題。
爲什麼應用層中的業務邏輯更適合企業應用。 ？ 好吧，從容易維護開始，應用層可以利用框架，爲您節省大量的時間和金錢，而不是重新發明輪子。利用線程或用於應用程序層的語言特定功能。
+1爲「不要重新發明輪子」 – 2011-03-02 16:42:46
我不清楚什麼「框架」與業務邏輯有關，也不知道爲什麼存儲過程涉及「重新發明輪子」。有人可以用一個例子來詳細說明嗎？ – 2011-03-02 17:08:12
數據庫獨立性非常小。當一家公司爲Oracle許可證支付大筆資金時，如果有人選擇將其丟棄並使用MS SQL，那麼您並不高興。 – SPee 2011-03-02 17:23:41
- 爲什麼數據庫中的業務邏輯有時候是EVIL？
- 多少時間和什麼時候業務邏輯 數據庫是一個很好的做法？
儘可能最小。我通常只在應用程序中的實現需要嚴重的數據庫性能時才使用它。出於這種原因，在PL/SQL中執行它是一個更好的選擇。
-爲什麼應用層中的業務邏輯更適合企業應用。 ？
答案與第一個答案相同。
這可能是一個糟糕的設計選擇（不做惡）如果
在我看來，迄今爲止所有的答案（包括我的！）都沒有給出問題的例子。他們大多隻是重申您所鏈接的線索中提出的感知問題，沒有任何可以討論的支持示例。例如「你不能單元測試乾淨」：我想看一個具體的例子。 – 2011-03-02 17:17:10
如果您沒有足夠的理由來對抗數據庫中的「業務邏輯」，那麼可能是因爲您的情況沒有足夠的理由，而且這可能是正確的做法。我建議你問自己，如果你沒有理由，你爲什麼要爭辯。 – 2011-03-02 22:27:39