Technologie-Inflation

Ein Artikel in der Zeitschrift iX hat mich heute darauf aufmerksam gemacht, dass zusammen mit dem Service Pack 1 für das .NET Framework 3.5 nun nach langem Warten die erste definitive Version des sogenannten ADO.Net Entity Framework zur Verfügung steht.

Es wurde schon eine ganze Menge darüber geschrieben, was es mit diesen „Entities“ auf sich hat. Z.B. ist die entsprechende Wikipedia-Seite ein guter Startpunkt, um sich einzulesen. Ich will deshalb nicht noch mehr Technisches darüber schreiben, sondern die Gelegenheit ergreifen, um ein bisschen über die Sache zu „philosophieren“.

Applikationen für vorwiegend administrative Zwecke, wie sie die Megos anbietet, sind sehr stark geprägt durch den Zugriff auf die Daten. Seit wir vor einiger Zeit beschlossen hatten, für die Programm-Entwicklung auf .NET umzusatteln, verfolgte ich deshalb ziemlich aufmerksam, was sich bei .NET in Sachen Datenzugriff und Datenverwaltung tut, und wurde schnell neugierig, als ich vor einiger Zeit zum ersten Mal von diesem Entity Framework hörte.

Was ich sah, als ich mich näher damit beschäftigte, hat mir zunächst fast die Sprache verschlagen: So ein Riesen-Ding, mit eigener SQL-Variante für die Abfrage, mit eigener Art von Datenbank-Modell, das über das relationale Modell hinausgeht, samt zugehörigem, nicht zu klein geratenem Modellierungs-Tool, plus jeder Menge neuer .NET-Klassen natürlich. Und fast noch bemerkenswerter als die Grösse der ganzen Geschichte kam mir deren Komplexität vor.

Dann wurde mir klar, dass .NET mit LINQ-to-SQL und dem Entity Framework gleich zwei Technologien enthalten wird, welche sich bezüglich der grundlegenden Aufgabe des sogenannten OR-Mapping überschneiden und konkurrenzieren. Die mögliche Antwort von Microsoft wird vielleicht – nicht unbedingt überraschend – noch mehr Neues, noch mehr Grosses und Komplexes sein, in Form von LINQ-to-Entities.

Ich habe mich unweigerlich gefragt, wie viele Leute wohl auf der Welt eine Datenbank bewirtschaften müssen mit einer Struktur, die so vielfältig und komplex ist, dass man dieses Entity Framework zum Einsatz bringen kann und netto etwas herausschaut dabei, will sagen: Der Gewinn an Funktionalität und Flexibilität beim Umgang mit der Datenbank in den .NET-Programmen wiegt die Arbeit auf, die man aufwenden muss, um sich in diese riesige Geschichte einzuarbeiten, und wiegt dazu noch den Ärger auf, den man hat durch Bugs, die es fast unweigerlich geben muss in so viel neuem Code.

Und die Frage „Soll ich auf das Entity Framework setzen?“ hat natürlich noch ganz andere Seiten. Soll ich meine Applikation um eine Technologie herum bauen, die ziemlich Microsoft-spezifisch ist? Wie langlebig wird diese Sache sein? Die Liste der Datenbank-Zugriffs-Technologien, die Microsoft zu „Legacy“ heruntergestuft hat, enthält schon einige Einträge (ODBC, DAO, OLE DB), und vielleicht kommt ja schon in relativ kurzer Zeit ein Eintrag dazu, wenn Microsoft sich eingestehen müsste, dass zwei OR Mappers einer zuviel ist.

Interessanterweise ist es mir bei einer Google-Suche als Vorbereitung auf das Schreiben dieses Blog-Eintrags nicht gelungen, Leute zu finden, die sich wie ich angesichts der Grösse, der Komplexität und des proprietären Anstrichs des Entity Framework Sorgen machen und erst einmal abwarten, bevor sie es einsetzen. Aber vielleicht ist es dafür einfach noch etwas zu früh…

Veröffentlicht in Keine Kategorie. Schlagwörter: , . Leave a Comment »

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: