Refactoring Implementierung von mehreren Klassen mit gemeinsamen Code (mit DI)

Question

Ich habe mehrere Subsysteme in einem großen System. So hat jedes Subsystem seine eigene BAL- und DAL-Implementierung. Jetzt haben die BAL (s) eine signifikante Logik, aber die DAL hatte im Grunde einen ähnlichen Code, so dass ich sie in eine generische DAL-Klasse umstrukturierte, die jetzt für alle Subsysteme verwendet wird. Etwas wie folgt aus:

Lassen Sie uns Subsystem Namen wie A und 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(); 
    } 
} 

Nun ist die DI Teil der Injektion generic DAL ist wichtig, von Unit-Tests Sicht übernehmen, so dass der BAL (n) die injizieren generisches DAL-Objekt. Jetzt ist die BAL unnötigerweise wegen der Refactoring- und DI-Anforderungen, die sie idealerweise nicht sein sollte (insbesondere beim Refactoring), unnötigerweise auf das generische DAL-Objekt aufmerksam.

Auch einer meiner Freunde wies darauf hin, dass die DAL (s) von Subsystem A und B nichts tun, also sollten wir sie wahrscheinlich loswerden und generische DAL selbst nennen, aber meiner Meinung nach reduziert es die Flexibilität als morgen DAL von A könnte eine Protokollierung oder eine andere spezielle Aktion ausführen, die B oder sogar C möglicherweise nicht abonnieren.

Also was denkst du? Hat jemand eine bessere refaktorierte Implementierung, wo der DI, die Trennung von Interessen (d. H. BAL von A kennt nur DAL von A und nicht allgemeines DAL-Objekt) und Flexibilität (mit verschiedenen DAL (s) für alle Subsysteme) intakt sind.

Eine der Möglichkeiten, die ich dachte, war, 2 Konstruktoren in DAL von A und B zu haben, so dass von BAL können wir ohne generische DAL-Injektion aufrufen und von Unit Test kann ich Generic DAL Objekt injizieren.

Answer 1

die DAL (s) von Subsystem A und B tun nichts, also sollten wir sie wahrscheinlich loswerden und generische DAL selbst nennen, aber meiner Meinung nach reduziert es die Flexibilität, wie morgen DAL von A vielleicht etwas tun möchte Protokollierung oder eine andere spezielle Aktion, die B oder sogar C möglicherweise nicht abonnieren.

Klassen sollten open for extension but closed to modification sein. Das bedeutet, dass das Hinzufügen von Protokollierung nicht bedeutet, dass Sie die DAL von A ändern müssen. Sie sollten dies tun können, indem Sie einen Dekorator erstellen, der die generische DAL umschließt. Das Gleiche gilt für andere bereichsübergreifende Anliegen.

So ist diese Flexibilität nicht IMO ein starkes Argument für in die zusätzlichen Schichten Indirektionsebene halten