關於分離問題的辯論（數據訪問vs業務邏輯）

我與同事就是否某些邏輯屬於數據訪問或業務邏輯層進行了辯論。關於分離問題的辯論（數據訪問vs業務邏輯）

這種情況是，BLL需要一些數據來處理。這些數據主要存在於數據庫中。我們希望緩存該數據（使用System.Runtime.Caching），以便在隨後的請求中快速提供。該體系結構使得DAL和BLL位於同一個盒子和不同的程序集中（同一解決方案中的項目）。所以不用擔心在電線或類似的東西上打DAL。

我的觀點是，打擊緩存與數據庫的決定是DAL關注的問題。業務邏輯層不應該關心數據來自何處，只是它獲取所需的數據。

他的觀點是數據訪問層應該是「純粹的」和「愚蠢的」，並且任何邏輯來決定打擊緩存與數據庫應該在業務邏輯層中。

在我看來，他所說的是破壞了關注點的分離，並導致圖層更緊密地耦合在一起，目標是讓事物鬆散耦合。如果它是一個特定的程序/用戶界面函數來決定數據的去向，我可以看到BLL可能想要控制的位置，但實際情況並非如此。這只是一個非常簡單的緩存場景，其中數據庫是主數據存儲。

的思考？

來源

2011-08-25 Will.NET

這可能是比較好的程序員。 –

將業務邏輯與數據分離的全部目的是讓您可以根據業務需求或技術更改將其交換出去。通過混合它們，你打敗了這個邏輯，因此，在理論層面上，你是正確的。然而，在現實世界中，我認爲你需要更加務實一點。應用程序的實際預期壽命是多少？技術將發生什麼變化？可能會有多少額外的工作將兩者分開？

來源

2011-08-25 14:49:32 John

爲了讓數據層緩存信息，我的初始反應與您的初始反應相同。這甚至可以與訂購數據庫中的更改的策略集成，或者實施輪詢以確保數據保持最新。但是，如果您打算在其他項目中重新使用數據層，或者即使不這樣做，在現有層和數據層之間實現新的業務層以處理緩存決策也不失爲一個好主意。因爲最終緩存不僅僅是一個性能問題，它還涉及關於併發和其他事務的商業決策。

一個n層系統就是這樣，你不限制你想要分成多少個層次。

來源

2011-08-25 14:51:48 Random

我同意你的100％。

緩存是DAL的一部分，不屬於BLL。

讓我們以hibernate爲例，它使用緩存系統來存儲您的實體。 Hibernate負責並知道如何控制他的緩存，（髒讀，刷新數據等）

你不想用所有這些低級數據邏輯混淆你的BLL。

問候

來源

2011-08-25 14:57:01 Cygnusx1

我知道我兩年多晚了比賽，但我想補充一點：

如果你有你的DAL定義的接口，你可以寫一個遵循的緩存機制該接口並管理'緩存與命中數據源'的關係，而不需要技術或源特定的DAL代碼不必擔心它，並且BLL不必擔心它。例如：

internal interface IThingsGateway 
{ 
    public Thing GetThing(int thingId); 
    public void UpdateThing(ThingUpdateInfo info); 
} 

internal class MsSqlThingsGateway : IThingsGateway 
{ 
    // implementation specific to MsSql here 
} 

internal class CachingThingsGateway : IThingsGateway 
{ 
    private IThingsGateway underlyingImplementation; 

    public CachingThingsGateway(IThingsGateway implementation) 
    { 
     this.underlyingGateway = implementation; 
    } 

    public Thing GetThing(int thingId) 
    { 
     if (this.HasCachedThing(thingId)) 
     { 
      return this.GetCachedThing(thingId); 
     } 

     var thing = this.underlyingGateway.GetThing(thingId); 

     this.SetCachedThing(thingId); 

     return thing; 
    } 

    public void UpdateThing(ThingUpdateInfo info) 
    { 
     this.underlyingGateway.UpdateThing(info); 

     this.ClearCachedThing(info.ThingId); 
    } 
}

如果我需要檢查多個數據源的事情，我會用同樣的方法：寫IThingsGateway的實現，處理耍弄各種數據源，委託給一個合適的邏輯。 ..然後在CachingThingsGateway換行即。客戶端代碼將最終從某個工廠或容器獲取IThingsGateway引用，這是發生包裝和實例化的地方。

而這一切都不需要額外的努力。如果使用緩存，則必須編寫該代碼，並且將其放入具有相同接口的另一個類所產生的開銷最小。

來源

2013-11-13 18:13:47 tuespetre

我相信緩存應該在業務層完成。當您嘗試從DAL獲取數據時，您可以檢查數據是否在緩存system.runtime.caching中可用，然後使用緩存數據，否則從數據庫中獲取數據。此外，如果您想由於某種原因使緩存失效，可以稍後通過調用業務中的函數來完成。

來源

2014-02-02 02:22:57 user2916578

關於分離問題的辯論（數據訪問vs業務邏輯）

回答

相關問題