具有通用代碼的多個類的重構實現（使用DI）

我在一個大系統中有多個子系統。所以每個子系統都有自己的BAL和DAL實施。現在，BAL具有重要的邏輯，但DAL基本上具有相似的代碼，因此我將它重構爲一個通用的DAL類，該類現在用於所有子系統。事情是這樣的：具有通用代碼的多個類的重構實現（使用DI）

假設子系統名稱爲A和B

public class DalA 
{ 
    private IGenericDal genericDal; 

    public DalA(IGenericDal injectedGenericDal) 
    { 
     this.genericDal = injectedGenericDal; 
    } 

    public bool DoSomeDBWorkForA() 
    { 
     return genericDal.CommonDalMethod(); 
    } 
} 


public class DalB 
{ 
    private IGenericDal genericDal; 

    public DalB(IGenericDal injectedGenericDal) 
    { 
     this.genericDal = injectedGenericDal; 
    } 

    public bool DoSomeDBWorkForB() 
    { 
     return genericDal.CommonDalMethod(); 
    } 
}

現在注入通用DAL的DI部分是從視功能單元測試點很重要，所以BAL（S）必須注入通用DAL對象。因此，現在BAL不必要地意識到通用DAL對象，僅僅是因爲重構和DI需求，理想情況下它不應該是（特別是在重構的情況下）。

另外我的一位朋友指出，子系統A和B的DAL（s）沒有做任何事情，所以我們應該擺脫它們並調用通用DAL本身，但在我看來，它降低了靈活性，因爲明天的DAL A可能想要做一些日誌記錄或其他一些B甚至C可能不會訂閱的特殊操作。

那麼你們怎麼看？在DI，關注點分離（即BAL的A只知道A的DAL而不是通用的DAL對象）和靈活性（對於所有子系統具有不同的DAL）完好無缺的情況下，任何人都有更好的重構實現。

我想到的方法之一是在A和B的DAL中有2個構造函數，所以從BAL我們可以調用而不注入通用DAL，並且從單元測試我可以注入通用DAL對象。

來源

2017-01-03 Rachit Pandey

恕我直言，這是錯誤的，有一個系統（解決方案）的有系統的所有部件內的多個子系統。使用微服務是更好的主意，或將子系統更改爲模塊;）。 –

@ shA.t這是一個很好的建議，但在這種情況下，我不能承受由於微服務實現而導致的延遲增加;）那麼在那種情況下，你會提出什麼建議？ –

子系統A和B都在做什麼，所以我們也許應該擺脫他們，並調用通用DAL本身的DAL（一個或多個），但在我看來，這降低了靈活性爲A的明天DAL可能想要做一些日誌記錄或B甚至C可能不會訂閱的其他特殊行動。

類應該是open for extension but closed to modification。這意味着添加日誌記錄並不意味着您需要更改A的DAL。您應該可以通過創建包裝通用DAL的裝飾器來完成此操作。其他交叉擔憂也是一樣。

所以這種靈活性是不是IMO保持間接的額外層的一個有力的論據

來源

2017-01-03 09:23:22 Steven

所以你說刪除中間的DAL（s）暫時是要走的路，修改應該通過裝飾器來處理，但是你不認爲DAL（s）在世界上很少處理太多的邏輯更廣泛的意義不應該總是（或者至少經常）以這種方式設計DAL，因爲大多數應用程序有多個模塊（因此多個DAL）需要處理？ –

@RachitPandey：是的，考慮到提供的信息，我建議刪除中間層。我無法評論「全球DAL」是如何設計的，因爲這裏有太多共同的口味。 – Steven

我同意現在刪除中間層，但會有一個異常，我希望你的想法。如果我直接從BAL調用通用DAL，那麼我確實需要提供一些「DAL特定參數」，如SP名稱等，我認爲BAL不應該真正意識到這一點。此外，我無法從通用DAL中刪除這些參數，以使其保持通用。 –

具有通用代碼的多個類的重構實現（使用DI）

回答

相關問題