Datenabstraktion mit ASP.Net 2.0

[Dennis R.]

Hallo,

wir müssen für ein Wahlpflichtfach (Studium der Tech. Informatik) eine Homepage (wir programmieren einen Vokabeltrainer) erstellen. Dabei sollen wir Datenbankabstraktion verwenden. Es gibt die Möglichkeit eine Klasse zu schreiben die die Anfragen weiterleitet. Nur stehen dabei die SQL-Befehle direkt im Quellcode. Mann kann die SQL-Befehle aber auch irgendwie auslagern, wie wird dies gemacht? Hat mir da jemand ne Beschreibung?

LG

[Rouven]

Hello,

wir müssen für ein Wahlpflichtfach (Studium der Tech. Informatik) eine Homepage (wir programmieren einen Vokabeltrainer) erstellen. Dabei sollen wir Datenbankabstraktion verwenden. Es gibt die Möglichkeit eine Klasse zu schreiben die die Anfragen weiterleitet. Nur stehen dabei die SQL-Befehle direkt im Quellcode. Mann kann die SQL-Befehle aber auch irgendwie auslagern, wie wird dies gemacht? Hat mir da jemand ne Beschreibung?

hmh, da fallen mir unter ASP.NET schon mehrere Punkt ein, an denen Datenabstraktion greifen könnte.

Verwende Objekte statt die Ergebnisse von SQL-Abfragen, d.h. bau dir ein einfaches Datenverwaltungsobjekt, das Wort und Übersetzung enthält. Wenn du dies nutzt ist für alle nachgelagerten Instanzen irrelevant, ob das Wort aus einer SQL-Abfrage oder einer Textdatei stammt.
Das ist aber wohl nicht der Hintergrund deiner Frage.

Kapsele _komplett_ die Datenzugriffslogik. ASP.NET hat verschiedene Zugriffsobjekte, die auf bestimmte Datenbanken zugeschnitten sind, anders herum gibt es Wrapper, die herstellerunabhängig sind - siehe hierzu MSDN: Writing Provider-Independent Code in ADO.NET, dort insbesondere das ganze Factories-Kapitel

Man kann anstatt SQL-Statements zu verwenden auf StoredProcedures ausweichen. Eine StoredProcedure wird direkt in der Datenbank abgelegt und ist von außen durch ihren Namen ansprechbar. Für die Datenbank hat dies den Vorteil, dass sie die Zugriffspfade schon im Voraus bestimmen kann, für die Anwendung hat es den Vorteil, dass eine Änderung an der Abfrage keine Änderung der Anwendung erfordert. Man ruft einfach die Procedure mit dem Namen auf. Nachteil: man kann nicht ohne weiteres die Anwendung schnappen und auf einen anderen Server werfen, man muss dort auch die Procedures erst anlegen. Aber, nachdem man das ja mit den Tabellen sowieso muss, ist der Nachteil vernachlässigbar.
Nochwas das für SP spricht ist der Umstand, dass auch SQL Dialekte kennt und man über StoredProcedures ggf. besser die Eigenheiten der Datenbank abfedern kann.

Du könntest die SQL-Befehle in eine Text- oder XML-Datei auslagern. Wenn du das entsprechend geschickt machst, dann stellt dir ASP.NET bereits sehr komfortable Zugriffsmethoden zur Verfügung, vgl. z.B. ConfigurationManager, wobei es sicherlich noch bessere gibt, Stichworte PropertyManager oder so, da bin ich gerade auf dünnem Eis.

MfG
Rouven

[Frank (no reg)]

Hallo, zusätzlich zu Rouvens Ausführungen ...

DataSets aus dem Namespace System.Data sind schon ganz brauchbare Datencontainer, die eine ganze Menge Logik mitbringen.

Die Abstraktion zwischen deinem Geschäftsobjekt (zb einem DataSet) und der Datenbank (mit der du fast zwingend mittels SQL kommunizieren musst), kannst du z.b. über automatisch oder manuell generierte DataTableAdapter (oder SqlDataAdapter) gewährleisten.

Du schreibst einfach eine Klasse DeinNamespace.DALKlasse (DAL = DataAccessLayer)

  
public class DALKlasse  
{  
  private SqlDataAdapter dataAdapter;  
  private SqlCommand cmdSelect;  
  private SqlCommand cmdInsert;  
  private SqlCommand cmdUpdate;  
  private SqlCommand cmdDelete;  
  private SqlConnection conn;  
  
  /// <summary>Der Konstruktor</summary>  
  public DALKlasse()  
  {  
     // rufe eine private methode zum initialisieren  
     this.InitializeAdapter();  
  }  
  
  /// <summary>Initialisierungsmethode</summary>  
  private InitializeAdapter()  
  {  
     this.  
     // baue dir die einzelnen vier CRUD SqlCommands  
     this.cmdSelect = new SqlCommand();  
     this.cmdSelect.CommandType = CommandType.StoredProcedure;  
     this.cmdSelect.CommandText = "dbo.GetData";  
     this.cmdSelect.Parameters.Add("@var", SqlDbType.Varchar, 100, ParameterDirection.Input, 0, 0, "SpalteVomDataSet", DataRowVersion.Original, null);  
     // jetzt kommt der schnee zum Update und so, und dann  
     this.dataAdapter = new SqlDataAdapter(this.cmdSelect);  
     this.dataAdapter.UpdateCommand = this.cmdUpdate;  
     // usw  
  }  
  
  /// <summary>Methode zum Daten lesen</summary>  
  public void GetData(DataSet yourDataSet, string deineVariable)  
  {  
     using(SqlConnection conn = new SqlConnection(  
ConfigurationManager.ConnectionStrings["deinConnectionString"].ConnectionString)  
     {  
        this.dataAdapter.SelectCommand.Parameters[0].Value = deineVariable;  
        this.dataAdapter.SelectCommand.Connection = conn;  
        this.dataAdapter.Fill(yourDataSet);  
     }  
  }  
}  

Die beiden hauptsächlichen Methoden deiner DAL Klasse sind dann nur

• GetData
• SetData

Wenn du auf der Datenbankseite StoredProcedures zur Verfügung stellst, kannst du leider nicht den SqlCommandBuilder benutzen, welcher dir aus einem SELECT ... FROM ... die anderen SqlCommands automatisch erstellen würde. Aber davon würde ich dir auch abraten.

Es gibt aber auch Frameworks, welche dir den gesamten DAL Code generieren, Stichwort: Olymars.

Für Technologie-Freaks gibt es mit dem neuen 3.5er .Net Framework LINQ, welches mit dem Objekt-Mapper von ADO.net arbeitet.

Wenn du einfach nur keine hartcodierten Texte im Quelltext stehen haben willst, kannst du diese einfach in eine Resource-Datei packen.

Wenn du die Daten an Controls (bzw andersherum) binden willst, empfiehlt sich die Verwendung eines DataSets.

Mit dem neuen ASP.Net 2.0 bzw. 3.x kann man doch auch einfach DataSources direkt in der Seite deklarativ definieren, samt allen möglichen Sql. In diesem Zusammenhang gestaltet dich Verwendung eines Objektes als Datenquelle dann nicht ganz so trivial. Aber das ist schon recht fortgeschrittenes.

HTH, Ciao, Frank