GUI, BLL, DAL Organisation in einem Projekt

Ich lese über Anwendungsebenen und möchte dieses Design in meinem nächsten Projekt (c #, .Net) verwenden. Einige Fragen:

1. Wird die Trennung von Ebenen über Namespaces vorgenommen? Project.BLL.Whatever, Project.DAL.Whatever

2. Ist es angemessener, nach Ebenen, dann nach Komponenten (Project.BLL.Component1) oder nach Komponenten und dann nach Ebenen (Project.Component1.BLL) zu trennen?

3. Ist diese Ebene für meine DAL mit verschiedenen Klassen weiter organisiert? Wenn alle Datenbankaufrufe in einer einzigen Klasse zusammengefasst sind, gibt es keine Organisation. Wäre es besser, diese mit verschiedenen Klassen oder Namespaces aufzuteilen?

4. Sind DAL-Klassen normalerweise statisch? Es erscheint umständlich, ein DAL-Objekt zu instanziieren, bevor jedes Mal eine seiner Methoden aufgerufen wird.

Alle anderen Tipps, wie Sie mit diesen Ebenen richtig vorgehen können, sind willkommen.

1. Ja. Und auch Baugruppen.
2. Ich würde nach Schichten und dann nach Komponenten trennen.
3. Ja. Es gibt verschiedene Ansätze dafür, aber ich hätte einen IDatabaseService (der die verschiedenen Arten abstrahiert, in denen die Datenbank aufgerufen wird - dies kann fast eine direkte Zuordnung von ExecuteScalar / ExecuteNonQuery / ExecuteReader sein) und dann verschiedene Datenzugriffsklassen, die Partition nach Datentyp. Beispielsweise könnten Sie eine UserDataAccess-Klasse haben, die einfache CRUD-Methoden zum Erstellen / Ändern / Löschen von Benutzerobjekten enthält. Ein anderer Ansatz wäre, ein Benutzerobjekt zu haben, in das die CRUD direkt integriert ist.

4. Nein, das macht den Unit-Test viel schwieriger. Sie sollten die Abhängigkeitsinjektion verwenden , um Abhängigkeiten an den Konstruktor jeder Datenzugriffsklasse (z. B. einen IDatabaseService) zu übergeben. Sie würden dann die Datenzugriffsobjekte wie folgt an die Geschäftsobjekte übergeben:

   BusinessObject businessObject = neues BusinessObject (neues DataAccessObject (neues DatabaseService ())); businessObject.PerformOperation ();

Jedes Geschäftsobjekt benötigt möglicherweise mehrere Datenzugriffsobjekte. Ihr GUI-Code würde auch ein oder mehrere Geschäftsobjekte verwenden. Einige Geschäftsobjekte benötigen möglicherweise keine Datenzugriffsobjekte, sollten den IDatabaseService jedoch niemals direkt verwenden.

Bei den Fragen 1 und 2 gehen Sie zu Matthews Antworten.

Ich habe viel Zeit damit verbracht, herauszufinden, wie die DAL von Desktop-Anwendungen am besten strukturiert werden kann. Und der beste Weg hängt wirklich von den Anforderungen der Anwendung ab. In einer meiner Apps habe ich eine DA-Klasse für jede Datenbanktabelle eingerichtet, die sich bei einer zentralen (dh Singleton-) DataProvider-Klasse registriert und die CRUD verarbeitet hat. Jede DA-Klasse könnte dann entscheiden, ob sie alle Tabellendaten im RAM zwischenspeichern möchte oder nicht (Leistung!) Und / oder ob sie die Fähigkeit haben muss, automatische Client-Updates in anderen Clients auszulösen, die auf anderen Computern ausgeführt werden (denken Sie an Mehrbenutzer) Parallelität). Dies macht das Hinzufügen neuer DAL-Klassen sehr einfach, da sie lediglich der Registrierungsschnittstelle entsprechen müssen.

Nicht jeder DAL benötigt diese Art von Funktionalität, aber ich habe gelernt, dass der Ansatz selbst (dh Singleton-Datenprovider und einfache DAL-Klassen mit statischer Registrierung) mein Leben viel einfacher machte, als ich anfing, neue Klassen hinzuzufügen.

Ich würde definitiv nicht empfehlen, die CRUD in höhere Klassen einzubauen, es sei denn, dies ist eine sehr einfache Anwendung. Die DAL ist eine Abstraktion des Datenspeichers. Wenn Sie sich entscheiden, Ihren Datenspeicher zu einem späteren Zeitpunkt zu ändern (auch wenn nur MySQL anstelle von MS SQL verwendet wird), sind Sie dafür sehr dankbar. Plus: BLL-Objekte sollten nach ihren Geschäftslogikbeziehungen strukturiert sein. DAL-Objekte sind nach den Arten von Speichercontainern strukturiert, die sie darstellen. Die Unterschiede können dramatisch sein.

Machen Sie Ihre DAL-Klassen NICHT statisch. Was Sie an Codierungsgeschwindigkeit gewinnen, verlieren Sie um ein Vielfaches an Testbarkeit und Flexibilität.