@ErfinderDesRades: hat ein Tutorial dazu gemacht, wie man ohne Code eine Datenbank erzeugen kann - und das relativ schnell und einfach.
Im Internet gibt es immer wieder Leute die behaupten, sie wüssten wie man mit Datenbanken richtig umgeht und diese zu nutzen hat - nein ErfinderDesRades gehört nicht dazu.
Durch meine Spielereien mit dem MVC4-Framework für ASP.NET Anwendungen ist mir aufgefallen, dass man ohne jegliche Modelle Datenbanken erzeugen kann, ohne sich um den Code zu kümmern - das einzige was man braucht, ist etwas Logik und drei Dateien.
Voraussetzungen, um dieses Tutorial durchzuarbeiten sind:
Nun, warum schreibe ich denn jetzt dieses Tutorial? Ganz einfach, ich möchte mein erlangtes "Wissen" auch der Außenwelt zur Verfügung stellen. Außerdem ist dieses Thema - EF - noch ein ziemlich Neues und nicht jeder hat sich bis jetzt damit auseinandergesetzt. Ich möchte außerdem eine grundsolide Struktur für mich bauen, da ich - praktisch jedenfalls - ein Gehirn wie eine Kartoffel habe, sodass ich hier immer wieder nachgucken kann und denke "jo, ist super, Copy&Pastest du das mal." -was jetzt nicht bedeuten soll, dass ich hier Copy&Paste-Code liefern werde, da hier auch einiges an Eigenarbeit gefordert wird.
Worum geht es jetzt in diesem Tutorial genau? Wie ich bereits sagte, werde ich die Grundzüge des EF und der Arbeit damit zeigen. Außerdem natürlich auch die Vorteile und - sofern vorhanden - auch die Nachteile.
Die Grundstruktur des Beispiels ist (wen wunderts)
Für den Einstieg in das EF wird a) das EF und b) noch weitere Verweise benötigt.
Das EF ist relativ einfach per
Die weiteren Verweise sind
Was diese einzelnen Bibliotheken aufsich haben, wird im Folgenden natürlich noch gezeigt. Außerdem ist dies auch erst der Anfang.
Wenn nun die Verweise ordnungsgemäß installiert und eingerichtet sind, kann mit der Grundstruktur der Logik angefangen werden - ich nutze hier eine kleine Datenbank mit einer Auflistung von User <-> Beitrag <-> Kommentar (vergleichbar mit Reddit, o.Ä.).
Dinge die berücksichtigt werden müssen, sind a) wie sollen die Datensätze miteinander verknüpft sein und b) wie sehen die Datensätze aus?
Der erste Punkt ist schnell abgearbeitet: User:Beitrag 1:n. Fertig. Nur, das Design der Datensätze ist nicht ganz klar.
Also erstmal ein geeignetes Modell aufbauen.
Was nun gebraucht wird, ist eine vollständige Umsetzung in VB-Code. Ebenfalls, aufgrund des Modells oben, nicht weiter schwierig.
Table und Key wird der Compiler vorerst anmeckern, das Problem: die Imports fehlen (sofern nicht schon vorher in der Verweis-Ansicht erledigt)
Für den User etwas eigenes:
Nun kommt aber etwas ganz komisches - die Eigenschaften, die sich auf andere Tabellen beziehen, müssen mit
Damit ergibt sich für den Rest der Klasse:
Damit ist das User-Model schon fertig und muss nicht mehr bearbeitet werden - sollten dennoch Änderungen angewendet werden müssen: kein Problem! Einfach ändern und es funktioniert.
Was nun gebraucht wird, sind die restlichen Models - Entry und Comment.
Hier wird analog vorgegangen, wie beim User. - ich gebe hier nur eine C&P-Vorlage, da sich der Code nicht weiter unterscheidet.
Da nun alle Models korrekt eingebaut wurden, kann mit dem DbContext angefangen werden - ein, u.U., schwieriges Unterfangen.
Zuerst wird das EntityFramework benötigt. Dies ist einfach via
Nach diesem Schritt wird die App.config erweitert:
Hier werden direkt zwei Dinge sichtbar: das EntityFramework wird intern gesetzt und hat auch eine ConnectionFactory - später dazu mehr.
Aber vorher doch nochmal die Verbindung zur Datenbank - nur wegen dieser wird das EntityFramework benötigt!
Der Grundaufbau einer Verbindung zu einer Datenbank ist relativ einfach:
Etwas wird allerdings, laut Visual Studio, noch gebraucht - ein Verweis auf
Die Verbindung will allerdings gefüllt werden, a) mit Code und b) einem/mehreren Konstruktor/en.
Ersteres kann einfach gemacht werden:
Ein DbSet ist also ein Datensatz von genau einem Model, hier User, Entry und Comment.
Der DbContext wird allerdings nicht funktionieren, da eine entsprechende Verbindung fehlt.
Daher wird noch ein Konstruktor benötigt. Hierzu sollte einmal der eigentliche DbContext angeschaut werden.
Hier ist nun eindeutig ersichtlich, dass einige Konstruktoren implementiert werden müssen - allerdings nicht alle!
In diesem Fall wird der
Hierbei kann der Konstruktor mit einem Namen (s. App.config - ConnectionStrings) oder einem ConnectionString aufgerufen werden - sehr interessantes Feature.
Ich werde beide Möglichkeiten beleuchten - wobei der Name eher uninteressant ist, daher ist dies auch als nächstes dran.
Für den Namen gilt allgemein folgendes:
Es wird also Sql Ce (Microsoft Sql Server Compact) verwendet - eine abgespeckte Variante vom Sql Server, die ohne Server-Instanz ausgeführt werden kann.
Bei dem ConnectionString für Sql Ce muss allerdings aufgepasst werden, dass der Aufbau korrekt ist. Daraus ergibt sich, dass der ConnectionString wie folgt lautet:
Wie sichtbar ist, wird der SqlServerCe4 Provider als auch der EntityClient verwendet .. warum?
Der EntityClient selber ist nur eine Schnittstelle zwischen dem SqlProvider und dem EntityClient - der SqlProvider ansich versteht keine "Linq" und muss deshalb durch einen anderen Provider irgendwie in eine nutzbare Sql-Query übersetzt werden. Dies tut der EntityClient.
Anders ist es, wenn versucht wird, auf einem Sql Server zu arbeiten:
Hier ist der Provider der SqlClient - spielt hier aber keine Rolle.
Es wird einfacher, sobald nurnoch der ConnectionString selber genutzt werden soll. Zwar ist eine Manipulierung der App.config angesagt, aber das soll nicht stören.
Die vorhin angesprochene
Hier ist also auch der SqlServer, der in den ConnectionStrings schon zusehen war, direkt eingebunden.
Was nun noch fehlt, ist der ConnectionString für den
Für diesen ist nicht soviel Wissen erforderlich, denn es gibt nicht viel mehr, was beachtet werden muss:
Welche Möglichkeit genutzt wird, liegt nicht in meinem Ermessen. Beide Möglichkeiten habe ihre Stärken und Schwächen.
Die Datenbank ist am Anfang, logischerweise, nicht initialisiert.
Dafür gibt es aber, eine kleine Abhilfe:
Ab jetzt ist die Verbindung offen und kann für alles genutzt werden.
Die Eigenschaften
Im Anhang ist ein Beispielprojekt was das Grundprinzip dahinter zeigt.
Dieses Projekt benötigt VS 2012 (Express Desktop) und neuer.
Vorschläge, Kritik (konstruktiv) gerne.
Im Internet gibt es immer wieder Leute die behaupten, sie wüssten wie man mit Datenbanken richtig umgeht und diese zu nutzen hat - nein ErfinderDesRades gehört nicht dazu.
Durch meine Spielereien mit dem MVC4-Framework für ASP.NET Anwendungen ist mir aufgefallen, dass man ohne jegliche Modelle Datenbanken erzeugen kann, ohne sich um den Code zu kümmern - das einzige was man braucht, ist etwas Logik und drei Dateien.
Voraussetzungen, um dieses Tutorial durchzuarbeiten sind:
- Wissen über Entity Framework (im Folgenden EF) /wie man dieses installiert
- Grundlagen der relationalen Datenbankentwicklung
- möglichst alle Grundlagen zur Programmierung draufhaben
- .NET 4.5 kann auch mit niedrigerem funktionieren - nicht getestet
- NuGet
Nun, warum schreibe ich denn jetzt dieses Tutorial? Ganz einfach, ich möchte mein erlangtes "Wissen" auch der Außenwelt zur Verfügung stellen. Außerdem ist dieses Thema - EF - noch ein ziemlich Neues und nicht jeder hat sich bis jetzt damit auseinandergesetzt. Ich möchte außerdem eine grundsolide Struktur für mich bauen, da ich - praktisch jedenfalls - ein Gehirn wie eine Kartoffel habe, sodass ich hier immer wieder nachgucken kann und denke "jo, ist super, Copy&Pastest du das mal." -was jetzt nicht bedeuten soll, dass ich hier Copy&Paste-Code liefern werde, da hier auch einiges an Eigenarbeit gefordert wird.
Worum geht es jetzt in diesem Tutorial genau? Wie ich bereits sagte, werde ich die Grundzüge des EF und der Arbeit damit zeigen. Außerdem natürlich auch die Vorteile und - sofern vorhanden - auch die Nachteile.
Die Grundstruktur des Beispiels ist (wen wunderts)
Für den Einstieg in das EF wird a) das EF und b) noch weitere Verweise benötigt.
Das EF ist relativ einfach per
install-package EntityFramework
in der NuGet-Konsole installiert - analog dazu kann auch der Wizard von NuGet genutzt werden.Die weiteren Verweise sind
System.ComponentModel.DataAnnotations
, System.Data.Entity
und System.Data.SqlServerCe
- hierbei nutze ich den SqlServerCe als Proof-Of-Concept, es kann jeder andere SqlProvider genutzt werden (auch SQLite.NET, allerdings habe ich dies nicht getestet).Was diese einzelnen Bibliotheken aufsich haben, wird im Folgenden natürlich noch gezeigt. Außerdem ist dies auch erst der Anfang.
Wenn nun die Verweise ordnungsgemäß installiert und eingerichtet sind, kann mit der Grundstruktur der Logik angefangen werden - ich nutze hier eine kleine Datenbank mit einer Auflistung von User <-> Beitrag <-> Kommentar (vergleichbar mit Reddit, o.Ä.).
Dinge die berücksichtigt werden müssen, sind a) wie sollen die Datensätze miteinander verknüpft sein und b) wie sehen die Datensätze aus?
Der erste Punkt ist schnell abgearbeitet: User:Beitrag 1:n. Fertig. Nur, das Design der Datensätze ist nicht ganz klar.
Also erstmal ein geeignetes Modell aufbauen.
Brainfuck-Quellcode
Was nun gebraucht wird, ist eine vollständige Umsetzung in VB-Code. Ebenfalls, aufgrund des Modells oben, nicht weiter schwierig.
Table und Key wird der Compiler vorerst anmeckern, das Problem: die Imports fehlen (sofern nicht schon vorher in der Verweis-Ansicht erledigt)
Für den User etwas eigenes:
VB.NET-Quellcode
- <Table("User")> _
- Public Class UserModel
- ' Die ID soll der Key der Tabelle sein
- ' und immer neu ausgerechnet werden
- <Key()> _
- <DatabaseGeneratedAttribute( DatabaseGeneratedOption.Identity )> _
- Public Property Id As Integer
- Public Property Name As String ' der Name des Users
- Public Property Password As String ' Passwort, wofür auch immer
- Public Property EMail As String ' passt schon.
Nun kommt aber etwas ganz komisches - die Eigenschaften, die sich auf andere Tabellen beziehen, müssen mit
Overridable
angegeben werden.Damit ergibt sich für den Rest der Klasse:
Damit ist das User-Model schon fertig und muss nicht mehr bearbeitet werden - sollten dennoch Änderungen angewendet werden müssen: kein Problem! Einfach ändern und es funktioniert.
Was nun gebraucht wird, sind die restlichen Models - Entry und Comment.
Hier wird analog vorgegangen, wie beim User. - ich gebe hier nur eine C&P-Vorlage, da sich der Code nicht weiter unterscheidet.
VB.NET-Quellcode
- <Table("Entries")> _
- Public Class EntryModel
- <Key()> _
- <DatabaseGeneratedAttribute( DatabaseGeneratedOption.Identity )> _
- Public Property Id As Integer
- Public Property Title As String
- Public Property Written As DateTime
- Public Property Content As String
- Public Overridable Property Author As UserModel
- Public Overridable Property Comments As List(Of CommentModel)
- End Class
VB.NET-Quellcode
- <Table("Comments")> _
- Public Class CommentModel
- <Key()> _
- <DatabaseGeneratedAttribute( DatabaseGeneratedOption.Identity )> _
- Public Property Id As Integer
- Public Property Written As DateTime
- Public Property Content As String
- Public Overridable Property Entry As EntryModel
- Public Overridable Property Author As UserModel
- End Class
Da nun alle Models korrekt eingebaut wurden, kann mit dem DbContext angefangen werden - ein, u.U., schwieriges Unterfangen.
Zuerst wird das EntityFramework benötigt. Dies ist einfach via
Install-Package EntityFramework
in der NuGet-Konsole installiert.Nach diesem Schritt wird die App.config erweitert:
XML-Quellcode
- <?xml version="1.0" encoding="utf-8"?>
- <configuration>
- <configSections>
- <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
- <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
- </configSections>
- <startup>
- <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
- </startup>
- <entityFramework>
- <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
- </entityFramework>
- </configuration>
Hier werden direkt zwei Dinge sichtbar: das EntityFramework wird intern gesetzt und hat auch eine ConnectionFactory - später dazu mehr.
Aber vorher doch nochmal die Verbindung zur Datenbank - nur wegen dieser wird das EntityFramework benötigt!
Der Grundaufbau einer Verbindung zu einer Datenbank ist relativ einfach:
Etwas wird allerdings, laut Visual Studio, noch gebraucht - ein Verweis auf
System.Data.Entity
.Die Verbindung will allerdings gefüllt werden, a) mit Code und b) einem/mehreren Konstruktor/en.
Ersteres kann einfach gemacht werden:
Ein DbSet ist also ein Datensatz von genau einem Model, hier User, Entry und Comment.
Der DbContext wird allerdings nicht funktionieren, da eine entsprechende Verbindung fehlt.
Daher wird noch ein Konstruktor benötigt. Hierzu sollte einmal der eigentliche DbContext angeschaut werden.
Hier ist nun eindeutig ersichtlich, dass einige Konstruktoren implementiert werden müssen - allerdings nicht alle!
In diesem Fall wird der
New(string)
Konstruktor implementiert.Hierbei kann der Konstruktor mit einem Namen (s. App.config - ConnectionStrings) oder einem ConnectionString aufgerufen werden - sehr interessantes Feature.
Ich werde beide Möglichkeiten beleuchten - wobei der Name eher uninteressant ist, daher ist dies auch als nächstes dran.
Für den Namen gilt allgemein folgendes:
Es wird also Sql Ce (Microsoft Sql Server Compact) verwendet - eine abgespeckte Variante vom Sql Server, die ohne Server-Instanz ausgeführt werden kann.
Bei dem ConnectionString für Sql Ce muss allerdings aufgepasst werden, dass der Aufbau korrekt ist. Daraus ergibt sich, dass der ConnectionString wie folgt lautet:
<clear />
wird verwendet, um mögliche andere Verbindungen zu löschen, diese sind uninteressant und brauchen nicht beachtet zu werden!Wie sichtbar ist, wird der SqlServerCe4 Provider als auch der EntityClient verwendet .. warum?
Der EntityClient selber ist nur eine Schnittstelle zwischen dem SqlProvider und dem EntityClient - der SqlProvider ansich versteht keine "Linq" und muss deshalb durch einen anderen Provider irgendwie in eine nutzbare Sql-Query übersetzt werden. Dies tut der EntityClient.
Anders ist es, wenn versucht wird, auf einem Sql Server zu arbeiten:
Hier ist der Provider der SqlClient - spielt hier aber keine Rolle.
Es wird einfacher, sobald nurnoch der ConnectionString selber genutzt werden soll. Zwar ist eine Manipulierung der App.config angesagt, aber das soll nicht stören.
Die vorhin angesprochene
defaultConnectionFactory
muss etwas erweitert werden:Hier ist also auch der SqlServer, der in den ConnectionStrings schon zusehen war, direkt eingebunden.
Was nun noch fehlt, ist der ConnectionString für den
DbContext
.Für diesen ist nicht soviel Wissen erforderlich, denn es gibt nicht viel mehr, was beachtet werden muss:
"Data Source=" & System.IO.Path.Combine( Environment.CurrentDirectory, "Test.sdf" )
Welche Möglichkeit genutzt wird, liegt nicht in meinem Ermessen. Beide Möglichkeiten habe ihre Stärken und Schwächen.
Die Datenbank ist am Anfang, logischerweise, nicht initialisiert.
Dafür gibt es aber, eine kleine Abhilfe:
Ab jetzt ist die Verbindung offen und kann für alles genutzt werden.
Die Eigenschaften
Configuration
und Database
sollten natürlich noch an die eigenen Gegebenheiten angepasst werden.Im Anhang ist ein Beispielprojekt was das Grundprinzip dahinter zeigt.
Dieses Projekt benötigt VS 2012 (Express Desktop) und neuer.
Vorschläge, Kritik (konstruktiv) gerne.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „AliveDevil“ ()