Es scheint, dass jeder weiß, dass Sie eine klare Unterscheidung zwischen der GUI, der Geschäftslogik und dem Datenzugriff haben sollten. Ich habe kürzlich mit einem Programmierer gesprochen, der damit prahlte, immer eine saubere Datenzugriffsschicht zu haben. Ich habe mir diesen Code angeschaut, und es stellt sich heraus, dass seine Datenzugriffsebene nur eine kleine Klasse ist, die einige SQL-Methoden umschließt (wie ExecuteNonQuery und ExecuteReader). Es stellt sich heraus, dass in seinem ASP.NET-Code hinter Seiten, hat er Tonnen von SQL hart in die page_load und andere Ereignisse codiert. Aber er schwört, dass er eine Datenzugriffsschicht verwendet.
Also, ich werfe die Frage raus. Wie würden Sie eine Datenzugriffsebene definieren?
Worüber Ihr Kollege spricht, ist für die meisten Leute kein DAL. Die DAL sollte alle Aufrufe an die Datenbank kapseln, sei es durch dynamisches SQL, gespeicherte Prozeduren oder ein ORM mit einem IRepository. Ihre Webseiten sollten niemals SQL oder Geschäftslogik enthalten, sonst wird es zum Wartungs-Albtraum.
Ein sehr einfaches Beispiel für .NET wäre wie folgt.
Wenn zwei Klassen haben: SomePage (eine ASP.NET-Seite) und DataService (was eine einfache alte C # -Klasse ist)
Wenn SomePage DataService immer zum Lesen / Schreiben von Daten aufruft, haben Sie eine Datenzugriffsschicht. SomePage enthält keine SQL oder Verweise auf System.Data.SqlClient-Klassen.
Aber SomePage kann DataSets oder Geschäftsobjekte verwenden, die von und an die DataService-Klasse übergeben werden.
Zusätzlich zu dem, was die anderen gesagt haben, halte ich es normalerweise für den Ort, an dem Sie abstrahieren können, wie Ihre Daten gespeichert werden. Eine wirklich gute Datenzugriffsschicht sollte es Ihnen ermöglichen, Oracle, SQL Server, Access, eine flache Textdatei, XML oder was immer Sie wollen auszutauschen, und dies wäre für die anderen Anwendungsschichten transparent. Mit anderen Worten, der Vertrag zwischen der Datenzugriffsschicht und anderen Schichten sollte in einer Datenbank agnostisch definiert werden.
Ich definiere persönlich die DAL als wo die Interaktionen zwischen meiner Anwendung und der Datenbank existieren. So kann ich eine Business-Schicht haben, die mit der DAL interagiert, um CRUD-Operationen zu ermöglichen.
EG Ich habe vielleicht eine ModelClass.LoadAll () -Methode, die mit der DAL interagieren würde, die die Daten abrufen würde, und die ModelClass würde diese Daten auf jede gewünschte Weise verwenden.
Ich bevorzuge es, die DAL so leicht wie möglich zu halten, aber einige andere Leute bevorzugen die andere Art, wo das Bestücken der Model Data in der DAL geschieht.
Eine Datenzugriffsebene greift auf Daten zu, und nichts anderes .
Ich würde gerne dieses Design von Data Retriever (schreibgeschützt) teilen.
Schlüssel für die Architektur:
DRO ( DataRetrieverObject ). DRO zu erreichen. Die Struktur basiert auf einer dreistufigen Konstruktion.
Verwenden Sie eine DataRetrieverFactory mit (überladenen) statischen Methoden, eine für jede Tabelle, die Sie benötigen. Verwenden Sie das Überladen, um verschiedene Arten von Schlüsseln zu finden. Die Methode gibt eine DRO zurück.
Der DataRetrieverFactory delegiert den Konstruktionsjob an eine zweite Klasse <TableNameAndKey>DR , die die eigentliche Anzeige erstellt.
In der <TableNameAndKey>DR haben wir eine statische Liste von Zeigern auf DROs, führen Sie eine Schleife durch, um zu sehen, ob Sie bereits eine DRO mit dem spezifischen Schlüssel haben.
3.1. Wenn Sie eine DRO finden - überprüfen Sie, ob es in Ordnung ist (was bedeutet:
3.1.1. Wenn die Anzeige in Ordnung ist, senden Sie die Anzeige zurück.
3.1.2. Wenn die Anzeige nicht OK ist, löschen Sie das Objekt (und seinen Zeiger) und erstellen Sie eine neue Anzeige mit Daten aus der Datenbank. Speichern Sie den Zeiger in der Liste.
3.2. Wenn in der Zeigerliste kein Treffer auftritt, erstellen wir eine neue Anzeige mit Daten aus der DB und speichern den Zeiger in der statischen Liste.
Mit dieser Technik kann man die DRO je nach Bedarf wiederverwenden, aber die Klasse ist kein Singleton, da wir viele Instanzen der Klasse haben dürfen.
Tags und Links data-access-layer