Praktische OData Rezepte

Standards sind eine tolle Sache – wenn sie einem tatsächlich Arbeit abnehmen. Leider gibt es selten etwas geschenkt, weshalb es in der Praxis immer wichtig ist Kosten und Nutzen gegeneinander abzuwägen. Dieser Beitrag soll beide Seiten kurz und knapp beleuchten um dir ein schnelles Abwägen zu ermöglichen. Wenn dann die Vorteile für deinen Anwendungsfall überwiegen, findest du hier gleich einsatzfertige Lösungen in Form von OData Rezepten – copy & paste ready 😉

Was ist OData?

Das halten wir mal ganz kurz: OData steht für Open Data Protocol. Der Standard wurde zwar von Microsoft initiiert, ist aber inzwischen ein ISO zertifizierter Standard, der auch außerhalb des Microsoft Universums Anwendung findet.

Der wichtigste Teil des Protokolls ich eine Abfragesprache (ähnlich wie SQL) mit der Daten selektiert werden können. Zum Einsatz kommt das in der Regel um an einem Client im Web (z.B. in JavaScript oder C# programmiert) eine Abfrage geben eine REST API zu formulieren. Eine solche OData REST API antwortet dann in einem wohl definierten Format, so dass der Client die gelieferten Daten verwenden kann.

Neben der Abfragesprache hängt an OData noch viel mehr. Z.B. werden alle verwendeten Datentype definiert und können von der API abgerufen werden. Außerdem kann eine vollständige OData Implementierung auch dafür genutzt werden Daten zu manipulieren.

Das soll jetzt aber erstmal für einen ganz groben Überblick reichen. Wer sich grundlegend über alle Möglichkeiten informieren will, dem sei die Site odata.org empfohlen.

Nachteile von OData

Der größte Nachteil ist meiner Meinung nach, dass man sich etwas in die Thematik einarbeiten muss. Wer also schon ein eine gute Vorlage in der Schublade hat, und jetzt vor einem weiteren Projekt steht, der kann wahrscheinlich am besten nochmal in die Schublade greifen und auch das nächste Projekt wie gehabt umsetzen.

Weiterhin ist natürlich die Einhaltung von Standards immer auch an gewisse Einschränkungen gebunden. Hier zeigt sich OData jedoch sehr flexibel. Es ist keine Alles-oder-Nichts-Lösung. Ich kann mir die Teile herauspicken, die mir nützen und den Rest gepflegt ignorieren.

Darüber hinaus bringt ein Protokoll auch etwas Overhead mit sich. Das sollte nur kurz erwähnt sein. Für den API Endpunkt auf den tausende von Requests einhämmern, kann man, wie gesagt, sich dann aus OData ausklinken und eine ganz tolle Highspeed Schnittstelle erfinden.

Vorteile von OData

Der größte Vorteil, den eine standardisierte Abfragesprache mit sich bringt ist ganz klar, dass man Vieles nicht mehr selbst erfinden muss. Für die Clientseite gibt es eine Reihe von Anbietern, die mächtige Data-Grids anbieten. Von DevExpress gibt es eine Lösungen für JavaScript und für Blazor gibt es fertige Komponenten von Radzen (kostenlos) und von Telerik.

Vereinfacht kann man also sagen, dass man nur eine fertige Komponente in den Client legt und automatisch von allem profitiert, was für die Darstellung großer Datenmenge wichtig ist. Man wälzt halt am besten alles, was mit großen Datenmenge zu tun direkt auf die Datenbank ab (Filtern und Sortieren). Die Zig Millionen von Datensätzen lassen wir also schön das Problem des Datenbanksystems sein und holen sie weder in den Hauptspeicher des Webservers noch übertragen wir sie zum Client.

Und das Beste kommt erst noch: Nachdem wir die Arbeit für die Abfrage und Darstellung der Daten am Client schon wegrationalisiert haben, stellen wir uns noch kurz die Frage: „Wie kommt die Abfrage in die Datenbank?“. Und auch hier gibt es zum Glück nahezu vollständige Unterstützung von Entity Framework bzw. Entity Framework Core.

Was Entity Framework Core (Kurz EF Core) ist, kann ich im Rahmen dieses Artikels nicht erklären. Wenn bei dem Begriff gar nichts klingelt, dann nur kurz so viel: Es ist ein ORM (Object Relational Mapper) von Microsoft. Es sorgt also dafür, den Bruch zwischen Relationaler Datenbank und objektorientierter Programmierung etwas zu glätten. Eine kleine Einführung in deutsch findest du z.B. hier.

Wer EF Core bereits im Einsatz hat oder zumindest kennt (oder die Wissenlücke gleich mit beseitigen will), kann direkt mit den folgenden Rezepten durchstarten:

Rezept 1: Ein minimaler OData fähiger API Endpunkt

Um einen OData-fähigen Endpunkt in ASP.NET 6 zu erstellen, müssen wir zuerst das NuGet-Paket Microsoft.AspNetCore.OData installieren und dann den Endpunkt in unserer Anwendung konfigurieren.

Jetzt können wir die OData-Dienste und Endpunkte in der Program.cs konfigurieren:

Jetzt brauchen wir noch eine Beispiel Entity und einen DbContext

Wir ersetzen „YourEntity“, „YourDbContext“ und „YourConnectionString“ durch entsprechende Werte, die zu unserer Anwendung passen. Schon haben wir einen OData-fähigen Endpunkt erstellt, der unter /odata/YourEntities erreichbar ist. Der Endpunkt unterstützt nun OData-Abfrageoptionen wie $filter, $select, $expand, $orderby, $skip und $top.