© ranjith ravindran/Shutterstock.com, © S&S Media
Windows Developer
Teil 2: .NET Core und MongoDB - Datenzugriff, Zugriffssteuerung und Abstraktion

ASP.NET Core loves MongoDB

Im Zuge der plattformübergreifenden Entwicklung von Web-APIs stellt sich natürlich auch die Frage nach einer zeitgemäßen Art und Weise der Datenspeicherung. Wer hier ebenfalls flexibel und plattformübergreifend arbeiten möchte, sollte einen Blick auf die aktuellen objekt- bzw. dokumentorientierten Datenbanken werfen.

Patrick Schnell


ArtikelserieTeil 1: ASP.NET-Core-Web-API effizient nutzenTeil 2: .NET Core und MongoDB – Datenzugriff, Zugriffssteuerung und Abstraktion

Jahrzehntelang dominierten relationale Datenbanksysteme und werden dies sicherlich noch einige Zeit tun. Jedoch sind objekt- bzw. dokumentorientierte Datenbanken immer mehr auf dem Vormarsch und bieten für viele Anwendungsfälle eine geeignete und flexible Lösung, um Daten zu persistieren und zu verwalten.

Ein großer Vorteil dokumentorientierter Datenbanken ist in erster Linie das schemalose Arbeiten mit Daten. Modelländerungen müssen nun nicht mehr in der Datenbank nachgepflegt und mit entsprechenden Formaten und Regeln ausgestattet werden, sondern können direkt umgesetzt werden. Bei den meisten NoSQL-Datenbanken ist es ebenfalls möglich, seinen Objekten wiederum untergeordnete Objekte zuzuordnen. Durch diese enorme Flexibilität werden vorhandene Klassenkonstrukte schlicht als Dokumente in der Datenbank abgelegt bzw. serialisiert und können sowohl in der Datenstruktur als auch in der Programmlogik äquivalent eingesetzt werden.

Im Falle der althergebrachten relationalen Datenbanksysteme, werden Datenstrukturen wie gewohnt in Tabellen mit fest konfigurierten Spalten und Zeilen hinterlegt. Dies erfordert jedoch, dass die Daten, die in der Anwendung generiert und als hierarchische Klassenstrukturen umgesetzt wurden, entweder manuell oder über einen Object-Relational Mapper als entsprechende zweidimensionale Daten aufzubereiten sind. Dies ist logischerweise immer mit Kompromissen verbunden und für viele heutige Anwendungsfälle eher hinderlich. Ein großer Teil der zur Verfügung stehenden Funktionalitäten in relationalen Datenbanksystemen wird in einfachen Anwendungen oftmals nicht genutzt oder bereits in andere, darauf spezialisierte Systeme (Analyse und Auswertungen, Suche etc.) ausgelagert. Demnach lohnt es sich bei Neuentwicklungen ebenfalls, einen Blick auf die vorhandenen NoSQL-Datenbanken zu werfen.

Eine der weitverbreitetsten NoSQL-Datenbanken ist MongoDB [1], die sich aufgrund der einfachen Konfiguration und dem geringen Speicherbedarf sehr für kleine verteilte Systeme eignet, dabei jedoch enorm skalierbar ist. In diesem Artikel erläutere ich Ihnen, wie Sie mithilfe von MongoDB und geeigneten Patterns bzw. Verfahren eine wartbare Datenzugriffsschicht für Ihr ASP.NET-Core-Web-API [2] umsetzen können.

Aufbau einer dokumentorientierten Datenbank

Wie bereits erwähnt, bietet MongoDB als dokument­orientierte Datenbank den Vorte...

Windows Developer
Teil 2: .NET Core und MongoDB - Datenzugriff, Zugriffssteuerung und Abstraktion

ASP.NET Core loves MongoDB

Im Zuge der plattformübergreifenden Entwicklung von Web-APIs stellt sich natürlich auch die Frage nach einer zeitgemäßen Art und Weise der Datenspeicherung. Wer hier ebenfalls flexibel und plattformübergreifend arbeiten möchte, sollte einen Blick auf die aktuellen objekt- bzw. dokumentorientierten Datenbanken werfen.

Patrick Schnell


ArtikelserieTeil 1: ASP.NET-Core-Web-API effizient nutzenTeil 2: .NET Core und MongoDB – Datenzugriff, Zugriffssteuerung und Abstraktion

Jahrzehntelang dominierten relationale Datenbanksysteme und werden dies sicherlich noch einige Zeit tun. Jedoch sind objekt- bzw. dokumentorientierte Datenbanken immer mehr auf dem Vormarsch und bieten für viele Anwendungsfälle eine geeignete und flexible Lösung, um Daten zu persistieren und zu verwalten.

Ein großer Vorteil dokumentorientierter Datenbanken ist in erster Linie das schemalose Arbeiten mit Daten. Modelländerungen müssen nun nicht mehr in der Datenbank nachgepflegt und mit entsprechenden Formaten und Regeln ausgestattet werden, sondern können direkt umgesetzt werden. Bei den meisten NoSQL-Datenbanken ist es ebenfalls möglich, seinen Objekten wiederum untergeordnete Objekte zuzuordnen. Durch diese enorme Flexibilität werden vorhandene Klassenkonstrukte schlicht als Dokumente in der Datenbank abgelegt bzw. serialisiert und können sowohl in der Datenstruktur als auch in der Programmlogik äquivalent eingesetzt werden.

Im Falle der althergebrachten relationalen Datenbanksysteme, werden Datenstrukturen wie gewohnt in Tabellen mit fest konfigurierten Spalten und Zeilen hinterlegt. Dies erfordert jedoch, dass die Daten, die in der Anwendung generiert und als hierarchische Klassenstrukturen umgesetzt wurden, entweder manuell oder über einen Object-Relational Mapper als entsprechende zweidimensionale Daten aufzubereiten sind. Dies ist logischerweise immer mit Kompromissen verbunden und für viele heutige Anwendungsfälle eher hinderlich. Ein großer Teil der zur Verfügung stehenden Funktionalitäten in relationalen Datenbanksystemen wird in einfachen Anwendungen oftmals nicht genutzt oder bereits in andere, darauf spezialisierte Systeme (Analyse und Auswertungen, Suche etc.) ausgelagert. Demnach lohnt es sich bei Neuentwicklungen ebenfalls, einen Blick auf die vorhandenen NoSQL-Datenbanken zu werfen.

Eine der weitverbreitetsten NoSQL-Datenbanken ist MongoDB [1], die sich aufgrund der einfachen Konfiguration und dem geringen Speicherbedarf sehr für kleine verteilte Systeme eignet, dabei jedoch enorm skalierbar ist. In diesem Artikel erläutere ich Ihnen, wie Sie mithilfe von MongoDB und geeigneten Patterns bzw. Verfahren eine wartbare Datenzugriffsschicht für Ihr ASP.NET-Core-Web-API [2] umsetzen können.

Aufbau einer dokumentorientierten Datenbank

Wie bereits erwähnt, bietet MongoDB als dokument­orientierte Datenbank den Vorte...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang