在獨立應用程序中，業務邏輯必須駐留在哪裏？

Question

我閱讀Tom Kyte的「有效的Oracle設計」。在那裏他說要將大部分代碼寫入數據庫本身以減少應用程序代碼。它在分佈式環境中很好，但它在獨立應用程序中是否有優勢？

我的應用程序。在.NET中。

Answer 1

IF你的數據庫將只支持單一的應用程序，並IF你休想相同的數據有不同的使用情況下，誰在使用它取決於和IF你永遠不會計劃使用不同的存儲機制......然後確保將業務邏輯放在數據庫中。

但是，如果其中任何一個是真的（如我懷疑）。那麼我和這個網站上的大多數人都會強烈建議你不要走這條路。

將邏輯放在數據庫中可能會引人注目，因爲您認爲「我可以隨時更改它！」但這是一條你不想走路的維修道路。傾聽經驗的聲音，並將您的疑慮分開。

我的應用程序。是一個獨立的Windows應用程序。 這是一個庫存和發票 解決方案。目前，我編寫了類 ，其中包含了執行各種插入，更新和 刪除操作的各種 數據庫操作的方法。我想知道，如果我可以在DB本身編寫 存儲過程，並且 只通過.NET 前端傳遞參數，那麼它可能會給 帶來什麼好處？

這實際上對我來說聽起來並不像商業邏輯，除非你正在做的不僅僅是CRUD操作。在這種情況下，無論您使用存儲過程，ORM還是手動生成的代碼查詢都是實現細節。

數據訪問層應該關心連接到數據存儲機制，但其他應用程序不應該關心。我將用一個例子說明：

public class MyDomainObject 
{ 
    public String Name {get; set;} 

    public Boolean IsValid() 
    { 
     return !String.IsNullOrWhitespace(Name) && 
      DoesNotContainInvalidCharacters(Name); 
    } 
} 

public class MyDataAccess 
{ 
    public List<MyDomainObject> GetAll() 
    { 
     //Some data access logic here 
    } 

    public MyDomainObject GetByName(String name) 
    { 
     //Some data access logic here 
    } 

    public void Save(MyDomainObject) 
    { 
     if(MyDomainObject.IsValid) 
     { 
      //Some data access logic here 
     } 
    } 
} 

所以，現在你有一個域對象和數據訪問對象。域對象實施了一些可以通過IsValid屬性檢查的平凡業務邏輯，數據訪問層使用它來確定是否應該保存它。但是，數據如何存儲的細節對域/業務層無關緊要。

如果你想重構使用存儲過程，那麼你的應用程序不應該真正關心。

Answer 2

是有很多的優勢，把業務邏輯在Oracle數據庫中，即使是獨立的應用程序：

• 性能和可擴展性，如該業務邏輯涉及訪問或更新數據庫
• 依賴跟蹤：很容易找到對代碼中的表和其他對象的引用
• PL/SQL是設計爲用於編寫訪問數據庫的代碼，非常簡單，並且無需構建大量動態SQL準備語句，或者使用像Hibernate這樣的混淆圖層來爲你做。

我真的偷Josh的答案，轉動180度：

如果你的數據庫將只 支持單個應用程序，以及IF 你休想相同的數據有 不同的使用情況取決於誰是 使用它......那麼肯定把業務邏輯 在...

應用程通貨膨脹。

我的意思是，你認真想要兩個不同的應用程序來訪問相同的數據行，但申請不同規則數據的更改？如果僅僅通過使用不同的訪問路徑就可以破解它，那麼擁有「規則」有什麼意義？

注意，我省略Josh的答案，這部分：

...如果你從來沒有打算 使用不同的存儲機制...

當然，如果您打算支持多個數據庫，或者拋棄Oracle並開始使用SQL Server或其他方式完全存儲數據，那麼您不會希望使用PL/SQL來編寫代碼。但是在許多情況下，這種情況不會發生，而且爲了自己的利益，您會不情願地追求數據庫獨立性。