Datenzugriffsschicht definieren

Question

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 aus. Wie würden Sie eine Datenzugriffsebene definieren?

Answer 1

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.

Answer 2

Eine "Black Box", die Ihre Daten enthält. Wenn es der Benutzer kümmert/sagen kann, dass es eine DB gibt (abgesehen von der Berücksichtigung), ist es nicht ganz das, was ich denke

Answer 3

Ich persönlich definiere die DAL als, wo die Interaktionen zwischen meiner Anwendung und der Datenbank bestehen . 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 in jeder gewünschten Weise verwenden.

Ich bevorzuge es, die DAL so leicht wie möglich zu halten, aber einige andere Leute bevorzugen den anderen Weg, wo das Bestücken der Modelldaten in der DAL passiert.

Answer 4

Zusätzlich zu dem, was die anderen gesagt haben, betrachte ich es normalerweise als den Ort, um herauszufinden, wie Ihre Daten gespeichert werden. Eine wirklich gute Datenzugriffsschicht sollte es Ihnen ermöglichen, Oracle, SQL Server, Access, eine flache Textdatei, XML oder was auch immer Sie möchten 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.

Answer 5

Ein sehr einfaches Beispiel für .NET wäre wie folgt.

Wenn zwei Klassen: Eineseite (das ist eine ASP.NET-Seite) und Dataservice (das ist eine gute alte C# Klasse ist)

Wenn Eineseite immer Data Anrufe/Schreib-Daten lesen Sie dann eine Datenzugriffsebene haben. 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.

Answer 6

Eine Datenzugriffsebene greift auf Daten zu, und nichts anderes.

Answer 7

fand ich diesen Artikel über eine DAL erstellen:

http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

Answer 8

Ich würde lieben diesen Entwurf von Daten Retriever (read-only) Schicht zu teilen.

Keys für die Architektur:

• Die Idee ist, ein Objekt zu erstellen, die fast Singleton ist (siehe unten), die Daten zu halten, die mit get-Methoden abgerufen werden - unter mir die DRO nennen (DataRetrieverObject).
• Es sollte einfach für das Clientobjekt sein, die DRO zu erreichen.
• Es sollte einfach sein, die Klassen zu pflegen.

Die Struktur basiert auf einer dreistufigen Konstruktion.

1. eine DataRetrieverFactory mit (überladenen) statischen Methoden, ein für jede Tabelle, die Sie benötigen Gebrauch. Verwenden Sie das Überladen, um verschiedene Arten von Schlüsseln zu finden. Die Methode gibt eine DRO zurück.

2. Die DataRetrieverFactory delegieren den Bauauftrag an eine zweite Klasse <TableNameAndKey>DR, die die tatsächliche DRO erstellen wird.

3. In der <TableNameAndKey>DR haben wir eine statische Liste von Zeigern zu DRO's, 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, ob es in Ordnung ist (was bedeutet:

   • es nicht "alt" sein sollte,
   • es zu einem Session-Laufe gehören soll,
   • etc.)

   3.1.1. Wenn die Anzeige OK ist - dann die Anzeige zurücksenden.

   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. Speichere 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 ein, die DRO Wiederverwendung kann je nach Bedarf, aber die Klasse ist nicht Singletons da dürfen wir viele Instanzen der Klasse haben.