Ein Datenbank-Framework verwenden

In den guten alten Zeiten, in denen PHP und ASP Classic das Internet beherrschten, wurde der Code zum Herstellen einer Verbindung mit einer Datenbank und zum Bearbeiten mit einer Datenbank normalerweise in Form einer Reihe von Funktionen und / oder Klassen in das Framework integriert. Diese Funktionen / Klassen würden für die meisten Zwecke ausreichen, da Sie sie einfach mit Befehlen an die Datenbank übergeben würden (häufig in Form von SQL-Abfragen) und sie mit den Ergebnissen entweder in Form von unformatierten Datenbankzeilen oder an eine Reihe von betroffenen Zeilen zurückgeben.

Heutzutage wird dies als etwas altmodisch angesehen. Stattdessen wird von Ihnen erwartet, dass Sie eine Art Framework verwenden, das viel oder fast alles von SQL abstrahiert (oder mit welcher Sprache auch immer Ihre Datenbank spricht), sodass Sie arbeiten können Objekte anstelle von Datenbankzeilen. Beispiele für diese Arten von Frameworks sind LINQ to SQL und .NET Entity Framework, wobei letzteres auch in einer Version für das Core .NET Framework (EF Core) vorhanden ist.

ORM - Objektbeziehungs Vergleich

Das Entity Framework ist ein sogenanntes ORM - ein Object-Relation-Mapper. Dies erleichtert die Kommunikation zwischen Ihrer Datenbank und Ihrem Code erheblich, da .NET Framework (und viele andere Programmiersprachen / Frameworks) Objekte verwendet, während eine relationale Datenbank Tabellen verwendet, um dasselbe darzustellen . Ein häufiges Szenario wäre dann, eine "Filme" -Tabelle in Ihrer Datenbank zu haben, um einen oder mehrere Filme darzustellen, und eine "Film" -Klasse in Ihrem .NET-Projekt, um jeden in der "Filme" -Tabelle gefundenen Film darzustellen.

Ohne ORM wären Sie für die Kommunikation zwischen Tabelle und Objekt verantwortlich: Wenn Sie die Datenbankzeilen herausziehen, müssten Sie die Movie-Objekte manuell auffüllen und beim Einfügen von Daten alle relevanten Eigenschaften vom Movie-Objekt an den SQL-Befehl hinzufügen, der es dann in die Datenbanktabelle einfügen würde.

Dank der ADO.NET-Klassen im System.Data.SqlClient-Namespace können Sie diesen Ansatz der alten Schule weiterhin verwenden. Das gibt Ihnen die Kontrolle, von der Sie träumen können, aber die Arbeit mit ihnen ist etwas umständlich - es gibt absolut keine Zuordnung zwischen Ihren Objekten und Datenbanktabellen, und selbst einfache Operationen erfordern mehrere Codezeilen und die Verwendung mehrerer Klassen wie SqlConnection. SqlCommand, SqlDataReader und so weiter.

Wenn Sie dagegen ein ORM verwenden, können Sie selbst mit einer einzigen Codezeile eine Menge tun, da in kurzen Befehlen viel Leistung steckt. Sie müssen kein SQL schreiben - stattdessen teilen Sie dem Framework mit, was Sie mit einem Befehl wie Select() erreichen möchten, und es wird in etwas umgewandelt, das die Zieldatenbank-Engine versteht, z.B.: SQL und im Gegenzug erhalten Sie einsatzbereite .NET-Objekte.

Der Nachteil dabei ist ein großer Kontrollverlust: Wenn Sie diese einfachen Befehle aufrufen, entscheidet das Framework, wie sie am besten gehandhabt werden. Wenn Ihre Datenbank an Größe und Komplexität zunimmt, kann es zu großen Leistungsproblemen kommen, da das ORM-Framework Ihre Daten und / oder Absichten nicht gut genug versteht, um sie in Befehle umzuwandeln, die eine ausreichende Leistung erbringen. Ein weiterer Nachteil ist, dass Sie möglicherweise nicht einmal verstehen, warum dies geschieht, da Sie bei all diesen Abstraktionen nicht wissen, was eine Datenbanktabelle ist und wie Sie mit ihr kommunizieren sollen.

ORM verwenden

In den meisten ASP.NET-Lernprogrammen, insbesondere den MVC-bezogenen, wird angezeigt, dass das Entity Framework verwendet wird. Dies ist wahrscheinlich auch die offizielle, von Microsoft empfohlene Lösung, wird jedoch in diesem Lernprogramm nicht verwendet. Es gibt mehrere gute Gründe dafür, wie oben dargelegt, aber der wichtigste ist, dass ich das Entity Framework nicht besonders mag. Ich habe es ein paar Mal versucht, aber ich habe mich nie wohl gefühlt mit dem Verlust der Kontrolle, den ich für die Benutzerfreundlichkeit bezahlt habe. Ein weiterer guter Grund, Dinge anders zu machen, besteht darin, Ihnen zu zeigen, dass es Alternativen gibt und dass es mit der enormen Flexibilität, die Sie mit dem .NET-Framework erhalten, immer möglich ist, Dinge anders zu machen.

Ich habe stattdessen einen Kompromiss zwischen dem sehr abstrakten Entity Framework und der einfachen Handcodierung von fast allem mit ADO.NET gewählt: Es heißt Dapper und wird oft als Mikro-ORM bezeichnet. Es abstrahiert die langweiligsten Dinge, während Sie trotzdem die volle Kontrolle darüber haben, wie alles gemacht wird.

Mit Dapper müssen Sie also nicht manuell zwischen Tabellen und Objekten zuordnen, aber Sie werden trotzdem die SQL schreiben, die die Daten abruft. Auf diese Weise erhalten Sie auch einige Kenntnisse über die zugrunde liegende Datenbank und deren Funktionsweise, von denen Sie später profitieren, insbesondere wenn Sie komplexere, datenintensive Projekte bearbeiten.

Eine andere coole Sache an Dapper ist die Tatsache, dass es einfach die IDbConnection -Schnittstelle erweitert, was bedeutet, dass Sie die vorhandenen Klassen für den Umgang mit Ihrer gewünschten Datenbank verwenden können (z.B.: SqlConnection, das IDbConnection implementiert) - mit anderen Worten Wenn .NET Ihre Datenbank unterstützt und Ihre Datenbank SQL unterstützt, können Sie wahrscheinlich Dapper verwenden!

Zusammenfassung

Wir haben jetzt eine Datenbank-Engine (MS SQL Server) und ein Datenbank-Framework / ORM (Dapper) ausgewählt. Danach müssen wir nur noch alles einrichten, damit wir unsere datenbankgesteuerte TodoList-Webanwendung erstellen können. Mehr dazu im nächsten Artikel.