Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Datenzugriff mit ADO.NET und .NET Core

Datenzugriffsvarianten

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Um mit .NET Core auf Daten(-banken) zuzugreifen, können Sie die Schnittstellen unterschiedlicher Frameworks nutzen. Neben ADO.NET Core und Entity Framework Core stellt der Trainer hier ein paar weitere Varianten vor und geht dabei unter anderem auch auf deren Performance ein.
09:21

Transkript

So, schauen wir uns doch mal an, welche Optionen es gibt, um mit .NET Core auf Daten zuzugreifen. Erst einmal gibt es da natürlich ADO.NET Core, momentan die Version 1.1, da kann ich relativ performant auf SQL Server SQLite zugreifen, bin aber sehr nah an der Architektur, das bedeutet, ich bin sehr nah an dem, was mein Datenbankserver denn nun versteht an der Stelle. Dann habe ich das Entity Framework, momentan auch Version 1.1. Da kann ich auf eine ganze Reihe von weiteren Datenbanken zugreifen, die sind Stand jetzt schon implementiert und ich habe natürlich den Vorteil, dass ich relativ datenbankunabhängig bin, aber da kommen wir gleich nochmal dazu. Dann gibt es als weitere Alternativen natürlich noch unzählige andere Möglichkeiten, die ich wahrscheinlich noch nicht einmal alle jetzt selber kenne, sehr bekannt sind aber NPoco, Drapper und auch das sind im Wesentlichen Technologien, mit denen ich auf Daten zugreifen kann, die alle so ein bisschen in die OR-Mapper-Schiene fallen. Was zeichnet das ADO.NET 1.1 denn aus? Wo sind denn die Vorteile? Ich habe die höchste Performance, wenn ich möchte, und ich kann alle Datenbank-Features ausnutzen. Das bedeutet, ich kann sehr genau meine Statements bauen und die gegen den Server schicken, was natürlich gleichzeitig ein Nachteil ist: Ich muss natürlich wissen, welche Statements ich denn wie formuliere, aber ich komme an jede kleinste Funktionalität meiner Datenbank ran und das muss sie auch nicht nur um Datenzugriffe handeln, sondern es könnten zum Beispiel auch Anweisungen sein, um den Server zu administrieren, um Objekte anzulegen in der Datenbank. Also ich kann "Create Table", ich kann "Create Procedure" und so weiter und so fort durchführen, alles kein Problem. Hauptsache dass das, was ich als Abfrage formuliere, auch wirklich gültiges Syntax hat. Wie gesagt, der Nachteil ist, ich bin dann von der Datenbank abhängig, weil bis auf einige Trivialbeispiele, ein "Sieh hin", ein "Sieh her", werden die einzelnen Datenbanksysteme sehr schnell ein Problem bekommen, wenn ich von Datenbanksystem A eine etwas komplexere Abfrage versuche, auf Datenbanksystem B auszuführen. Insofern, ich bin dann von meiner Datenbank abhängig. Wenn es natürlich letztendlich kein Problem ist und bei Ihnen möglicherweise auch kein Technologiewechsel ansteht, das heißt, Sie beispielsweise auf SQL Server aktuell unterwegs sind, und nach allem, was Sie wissen, und was Sie planen können, das auch nie ändern werden in den nächsten Jahren, dann ist das sicherlich kein sehr großer Nachteil. ADO.NET Core, auch da fehlen eine ganze Reihe von Features noch, die es im Vergleich zu Classic oder zum Full Framework gegeben hat, da werde ich dann an geeigneter Stelle entsprechend darauf zurückkommen. Wichtig aber, wenn Sie mit ADO.NET Core arbeiten, dann müssen sehr genaue Kenntnisse vorhanden sein. Die Framework ist ein bisschen so etwas wie eine Komfortecke, da kann ich es mir erlauben, vielleicht mal nicht genau zu wissen, was ich mache, gut ist es so oder so nicht, aber es wird wahrscheinlich in einigen Fällen sogar noch ganz gut funktionieren. Hier werden Sie relativ schnell die rote Karte bekommen. So, das Entity Framework Core hat auch eine ganze Reihe von Vorteilen, so ist das nicht. Ich würde auch für viele Anwendungen in der Tat wirklich auch Core benutzen, beziehungsweise Entity Framework Core benutzen. Es ist plattformübergreifend, es ist datenbankunabhängig, es ist lightwired, das heißt, im Vergleich zum Entity Framework 6.x ist das natürlich etwas, was nicht in einer Assembly oder in zwei Assemblys daherkommt, sondern wirklich nach der Philosophie des .NET Framework Cores in viele kleine Pakete aufgeteilt ist und das macht es natürlich sehr interessant. Gerade die Datenbankunabhängigkeit ist ein interessantes Thema, wenn Sie eine Anwendung entwickeln wollen, die möglicherweise auf unterschiedlichen Datenbanken läuft, ist eigentlich das Entity Framework oder generell ein OR-Mapper unverzichtbar. Auch hier fehlen sehr viele Features, muss man leider noch sagen, und es wird wahrscheinlich auch noch Jahre brauchen, bis das entsprechend so weit die Features auch aufgeholt hat, sofern sie auch eingebaut werden im Vergleich zum Entity Framework 6.x, das natürlich einiges an Zeit mehr zur Verfügung hatte, um weiterentwickelt zu werden und auch zu reifen an der Stelle. Hier fehlt schlicht und ergreifend noch einiges. Genaue Erkenntnisse sollen vorhanden sein und selbst wenn sie aber an der einen oder anderen Stelle da mal die ein oder andere Lücke haben, es wird trotzdem funktionieren. Das Entity Framework ist wirklich, so wie ich sagte, die Komfortecke, und da kann ich letztendlich mich drauf verlassen, dass vieles in meinem Sinne ausgeführt wird, aber trauen Sie dem Entity Framework oder trauen Sie generell allen OR-Mappern natürlich nicht einfach blind. Schauen Sie immer, was an Statements gebaut wird und was gegen die Datenbank geschickt wird. Kleiner Performancevergleich. Wie lese ich diese Grafik? Relativ leicht. Ganz links DataReader ist die schnellste Möglichkeit, Daten zu lesen mit ADO.NET, das soll mal die "1" sein. Es geht jetzt also nicht um Sekunden oder Minuten oder wie viele Gigabyte, Megabyte oder Ähnliches gelesen werden, sondern einfach nur um eine gewisse Relation zu bekommen. Es heißt letztendlich, die schnellste Möglichkeit bekommt hier die "1" und alles andere ist potentiell langsamer. Aber wenn ich jetzt mal mir die einzelnen Graphen angucke, beziehungsweise einzelnen Balken in dem Graphen angucke, dann werden Sie sehen, dass zum Beispiel das Entity Framework Core 1.1 mit .NET Core und "No Tracking" entsprechend auf 1,7 liegt, oder das Entity Framework 1.1 auf .NET Framework 4.6. Also auch das kann ich machen. Ich kann das Entity Framework Core auf dem klassischen .NET-Framework laufen lassen. Es ist quasi nur doppelt so langsam, wie die schnellste Möglichkeit, die ich mit ADO.NET habe. Bevor Sie jetzt in Verzückung geraten und denken: "Ja, warum benutze ich jetzt überhaupt das Entity Framework? ADO.NET ist doch viel schneller!" Man muss das ein bisschen relativieren. Der DataReader liest die Daten nur ein, die Sie dann in einer Art "Forward-Only-Cursor" haben im Variable, während das Entity Framework, sei es jetzt das Core als auch das klassische, natürlich viel mehr macht. Es erzeugt mir ganze Listen und ganze Bäume von Objekten und das ist natürlich eine ganz andere Baustelle, also da passiert natürlich auch sehr viel mehr. Insofern ist es schon faszinierend, dass Microsoft geschafft hat, die Performance so weit zu optimieren in Entity Framework Core, dass man nur 1,7x langsamer ist an der Stelle. Also durchaus eine sehr gute Leistung. Dann gibt es hier auch so einige andere Varianten, die man benutzen kann. Man könnte theoretisch das Entity Framework 6.x entsprechend mit Tracking verwenden, also "Auto Detect Changes on" zum Beispiel und dann sehen Sie: Es ist das 10,7-fache. Also das ist dann relativ langsam an der Stelle. Nichtsdestotrotz ist das natürlich vielleicht nicht das maßgebende Kriterium. Performance sagt ja einfach nur, wie schnell sind Zugriffe, bestenfalls lesende Zugriffe, wie schnell kann ich mit den Daten hantieren? Allerdings müssen Sie natürlich auch überlegen, dass es auch andere Kriterien gibt. Performance ist nicht alles und es kann schlicht und ergreifend sein, dass so etwas wie Wartbarkeit der Anwendung, Entwicklungsgeschwindigkeit und Ähnliches eine Rolle spielen. Also es kann natürlich sein, dass etwas 10x oder 11x langsamer ist, aber trotzdem noch pfeilschnell. Insofern würde ich da nicht unbedingt alles auf die Performance setzen. Ich würde eher, wenn es um die Frage geht "Benutze ich das ADO.NET oder benutze ich das Entity Framework?", mich fragen: "Was ist die Kernaufgabe meiner Anwendung? "Ist die Kernaufgabe das Administrieren, das Arbeiten mit Daten, "müssen Daten hin und her in irgendeiner Form exportiert, importiert werden oder Ähnliches?" Dann ist sicherlich das ADO.NET, weil es auch viel näher an der Datenbank ist und weil es auch dann wirklich noch sehr performant sein kann, entsprechend die bessere Wahl. Wenn es aber darum geht, eine Business-Anwendung anzulegen und zu entwickeln, dann macht es sicherlich viel mehr Sinn, das auch mit dem Entity Framework zu tun, weil ich da natürlich viel größere Möglichkeiten habe, und es ist heutzutage im Jahr 2017 nicht mehr so, dass ich jedes einzelne Select-Statement von Hand schreiben muss. Wie gesagt, aber trotzdem sehr interessant zu sehen, wie schnell das Entity Framework Core sein kann. Dann gibt es natürlich noch eine ganze Reihe weiterer Alternativen, wie ich auf Daten zugreifen kann. Es fängt natürlich mit den sogenannten NoSQL-Datenbanken an, also vorneweg Azure DocumentDB, MongoDB, Raven, Redis und so weiter und so fort. Das sind natürlich auch alles Möglichkeiten, um Daten abzuspeichern und Daten abzufragen. Das sind allerdings dann alle Alternativen, die eigene STKs haben, die eigene RPs haben, und wo ich entsprechend sehr genau gegen die einzelne Plattform programmieren muss an der Stelle. Die fallen so ein bisschen möglicherweise aus dem Raster noch raus. Es kann sein, es ist der Plan von Microsoft, dass das Entity Framework Core auch für nichtrelationale Datenbanken mal funktional sein wird, also dass ich da möglicherweise direkt eine Azure DocumentDB oder meinetwegen Redis oder Ähnliches ansprechen kann. Also das wird die Zukunft zeigen, was da implementiert wird und den Benutzern zur Verfügung gestellt. Keine Alternativen allerdings sind Technologien, die beispielsweise Windows-only sind, wie die OLE DB. Das heißt, da habe ich nicht die Möglichkeit, wirklich zu hoffen, dass das mal im Core eingebaut wird, weil das würde gegen die Plattformunabhängigkeit sprechen. Zur Zeit gilt das auch für ODBC. Auch hier gibt es noch keine Unterstützung im Bereich .NET Core.

Datenzugriff mit ADO.NET und .NET Core

Lernen Sie, wie mit Ihrer .NET Core-Anwendung auf relationale Datenbanken wie z.B. SQL Server oder SQLite zugreifen.

2 Std. 49 min (28 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:12.04.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!