Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
In vorangegangenen Artikeln haben wir Prozeduren erstellt, mit denen wir das Datenmodell einer Access-Datenbank einlesen und daraus ein Entity Data Model erstellen können. Zusätzlich haben wir auch noch die enthaltenen Daten ausgelesen und Code erzeugt, mit denen eine auf Basis des Entity Data Models erstellte SQL Server-Datenbank gefüllt werden kann. In diesem Artikel wollen wir einen Schritt weitergehen: Bisher haben wir den Code in die Zwischenablage kopiert, sodass der Benutzer diesen noch in die entsprechenden Module des Visual Studio-Projekts kopieren musste. Nun wollen wir direkt die passenden Module als Dateien erstellen, die nur noch in das Projekt gezogen werden müssen.
Die Artikel, in denen wir das Erstellen des Entity Data Models auf Basis des Datenmodells einer Access-Datenbank beschrieben haben, heißen Von Access zu Entity Framework: Datenmodell (www.datenbankentwickler.net/148), Von Access zu Entity Framework: Daten (www.datenbankentwickler.net/1) und Von Access zu Entity Framework: Update 1 (www.datenbankentwickler.net/164).
Die hier beschriebenen Prozeduren im VBA-Projekt einer Access-Datenbank lesen die Struktur des Datenmodells der Datenbank aus, die migriert werden soll, und schreibt die ermittelten Codezeilen in die Zwischenablage. Von dort aus sollen diese dann in die betroffenen Zielmodule des Visual Studio-Projekts eingefügt werden. Das ist noch etwas unkomfortabel, sodass wir die Lösung upgraden wollen – und zwar so, dass wir im Verzeichnis der Access-Datenbank neue Dateien und Verzeichnisse erhalten, die wir direkt in den Projektmappen-Explorer von Visual Studio ziehen können.
Wie soll die Lösung aussehen
Der Ausgangspunkt ist wieder, dass Sie in dem Projekt mit dem zu erstellenden Entity Data Model ein neues Element des Typs ADO.NET Entity Data Model hinzufügen (siehe Bild 1). Hier geben Sie direkt die Bezeichnung der Context-Klasse an, die wir später beim Zugriff über das Entity Data Model auf die in der Datenbank gespeicherten Daten verwenden werden – in diesem Fall RechnungsverwaltungContext.
Bild 1: Neues ADO.NET Entity Data Model-Element hinzufügen
Im nächsten Schritt wählen wir dann den Eintrag Leeres Code First-Modell aus (siehe Bild 2). Damit erscheint im Projektmappen-Explorer zunächst ein neues Element mit dem Namen, den wir dem neuen ADO.NET Entity Data Model-Element zugewiesen haben.
Bild 2: Die Wahl fällt auf Leeres Code First-Modell.
Für die Erstellung des Entity Data Models auf Basis des Datenmodells einer Access-Datenbank merken wir uns diese Bezeichnung.
Die Erstellung erfolgt dann durch einen einmaligen Aufruf einer Prozedur namens EDMDateienErstellen. Diese erwartet drei Parameter:
- bolEineDatei: Gibt an, ob die Entitätsklassen direkt in die Contextklasse geschrieben werden sollen oder als einzelne Dateien in ein Unterverzeichnis.
- strContextname: Erwartet den Namen des zuvor erstellten ADO.NET Entity Data Model-Elements.
- strUnterverzeichnisEntities: Name des Unterverzeichnisses, in das die einzelnen Klassendateien mit den Entitäten geschrieben werden sollen.
Ein Beispielaufruf sieht etwa wie folgt aus:
EDMDateienErstellen False, "RechnungsverwaltungContext", "DataModel"
Das Ergebnis finden Sie in Bild 3. Die Datei RechnungsverwaltungContext.vb enthält die Anweisungen, die Sie auch in der vom Assistenten erstellten gleichnamigen Datei vorfinden – erweitert um die Definition der DbSet-Auflistungen wie zum Beispiel die folgende:
Bild 3: Ergebnis nach dem Aufruf der Prozedur EDMDateienErstellen
Public Overridable Property Anreden() As DbSet(Of Anrede)
Das Verzeichnis DataModel enthält die Dateien aus Bild 4. Jede dieser Dateien enthält die Definition einer Entität des Entity Data Models. Die für die Tabelle tblAnreden sieht etwa wie folgt aus:
Bild 4: Inhalt des Unterverzeichnisses DataModel
Imports System.ComponentModel.DataAnnotations
Imports System.ComponentModel.DataAnnotations.Schema
<Table("Anreden")>
Public Partial Class Anrede
Public Property ID As System.Int32
<Index(IsUnique:=true)>
<StringLength(255)>
<Required>
Public Property Name As System.String
End Class
Das Ergebnis entspricht also inhaltlich dem aus den in den weiter oben referenzierten Artikeln beschriebenen Prozeduren – mit dem Unterschied, dass diese nun direkt in einem handlichen Verzeichnis liegen. Auf die gleiche Weise werden auch die übrigen Entitätsklassen in jeweils einer Datei in das Verzeichnis kopiert.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo