So wie es war
Seit Jahren organisiere ich meine Softwarelösungen als solche:
- Data Access Layer (DAL), um das Geschäft mit dem Zugriff auf Daten zu abstrahieren
- Business Logic Layer (BLL) zum Anwenden von Geschäftsregeln auf Datensätze, zum Behandeln der Authentifizierung usw.
- Dienstprogramme (Util), die nur eine Bibliothek gängiger Dienstprogrammmethoden sind, die ich im Laufe der Zeit erstellt habe.
- Präsentationsschicht, die natürlich Web, Desktop, Mobile oder was auch immer sein kann.
So wie es jetzt ist
In den letzten vier Jahren habe ich das Entity Framework von Microsoft verwendet (ich bin überwiegend ein .NET-Entwickler), und ich stelle fest, dass das DAL aufgrund der Tatsache, dass das Entity Framework das bereits durchgeführt hat, umständlicher als sauber wird Aufgabe, die mein DAL früher erledigt hat: Es abstrahiert das Geschäft, CRUDs für eine Datenbank auszuführen.
Daher habe ich normalerweise eine DAL mit einer Sammlung von Methoden wie dieser:
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
In der BLL wird diese Methode dann als solche verwendet:
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
Dies ist natürlich ein einfaches Beispiel, da bei der BLL normalerweise mehrere weitere Logikzeilen angewendet werden, aber es scheint nur ein wenig übertrieben, eine DAL für einen so begrenzten Bereich beizubehalten.
Wäre es nicht besser, einfach die DAL aufzugeben und einfach meine BLL-Methoden als solche zu schreiben:
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
Ich denke aus den oben genannten Gründen darüber nach, die DAL aus zukünftigen Projekten zu streichen, aber vorher wollte ich die Community hier nach Ihrer Rückschau / Voraussicht / Meinung befragen, bevor ich mich auf ein Projekt einlasse und ein Problem entdecke, das ich nicht habe. ' nicht vorwegnehmen.
Alle Gedanken werden geschätzt.
Aktualisieren
Der Konsens scheint zu sein, dass ein separater DAL nicht erforderlich ist, aber (hier meine eigene Schlussfolgerung zu ziehen) eine gute Idee ist, um eine Lieferantenbindung zu vermeiden. Wenn ich beispielsweise einen DAL habe, der EF-Aufrufe wie oben dargestellt abstrahiert, wenn ich Wechseln Sie jemals zu einem anderen Anbieter. Ich muss meine BLL nicht neu schreiben. Nur die grundlegenden Abfragen in der DAL müssten neu geschrieben werden. Trotzdem fällt es mir schwer, mir ein Szenario vorzustellen, in dem dies passieren würde. Ich kann bereits ein EF-Modell einer Oracle-Datenbank erstellen. MSSQL ist eine Selbstverständlichkeit. Ich bin mir ziemlich sicher, dass auch MySQL möglich ist (??), daher bin ich mir nicht sicher, ob der zusätzliche Code jemals einen lohnenden ROI erzielen würde.
GetMyObjects(int myId)einfacher ist als das Verspotten / Stubben / Fälschen GetObjects.Where(ob => op.accountId == myId).ToList().