Kolumne: Dino talks

Im Brennpunkt einfacherer Datenzugriff
Kommentare

Kürzlich hat Microsoft eine aufpolierte Version von WebMatrix veröffentlicht – eine kostenlose und einfache IDE für die schnelle Entwicklung von Websites, die erstmalig vor einigen Jahren eingerichtet wurde. Die neueste WebMatrix umfasst eine Expressversion von IIS, ASP.NET-Webseiten und eine eingebettete dateibasierte Datenbank, die mit SQL Server kompatibel ist. WebMatrix hat vor allem die Aufgabe, die Entwicklung von Websites zu vereinfachen, um sie zum einen für Gelegenheitsprogrammierer zugänglich und für Experten beträchtlich schneller zu machen, wenn es lediglich darum geht, sehr einfache und oftmals temporäre Lösungen umzusetzen.

In diesem Artikel konzentriere ich mich auf die eingebettete Datenbank und das Datenzugriffs-API, das sie unterstützt. Zugegebenermaßen habe ich gemischte Gefühle bei WebMatrix und den verwandten Produkten und Technologien. Einerseits erkenne ich die Anstrengungen hinter den Produkten an, um Webentwicklung für einen größeren Interessentenkreis – vor allem für nichtprofessionelle Entwickler – praktikabel zu machen. Andererseits befürchte ich, dass ein gewisser überschwänglicher Hype, den man unweigerlich in Blog-Posts findet, manche Leute dazu bringt, die wirklichen Ziele von WebMatrix und Konsorten zu verfehlen.

Insgesamt glaube ich, dass die Perspektive von WebMatrix mit der inneren Bedeutung des KISS-Akronyms – Keep it Simple, Stupid – konform geht. Eine allgemein akzeptierte Definition von „Einfachheit“ in der Softwareentwicklung ist, dass es sich bei einfachem Code um Code handelt, aus dem sich nichts entfernen lässt, ohne dass er dadurch scheitert oder sich falsch verhält. Einfachheit ist eng verknüpft mit diesen Zielen und den Aufgaben, die Sie realisieren müssen. Wenn Sie eine unternehmensgerechte Branchenanwendung erstellen, sind Sie wahrscheinlich mit einem Entitätsmodell vertraut, das auf bestimmte physische Tabellen abgebildet wird, mit einem O/RM ausgestattet ist, um Operationen auszuführen, und über einige Dienstschichten und Komponenten verfügt, um Testbarkeit und Trennung von Aufgabenbereichen zu verbessern.

Diese ganze Palette von Praktiken und Technologien ist wahrscheinlich überzogen, wenn Sie lediglich eine einfache Website konzipieren müssen, die nur für einige Monate läuft, praktisch schreibgeschützt ist oder irgendwie keine entscheidende Rolle im umgebenden Geschäftskontext spielt. Ob Sie Student, Gelegenheitsprogrammierer oder professioneller Entwickler sind, es ist die inhärente Einfachheit oder Komplexität der zu implementierenden Lösung, die bestimmt, wie am besten vorzugehen ist und welche Technologie sich am besten eignet. In diesem Sinne sind WebMatrix und der einschlägige Satz von vereinfachten Technologien inklusive Datenzugriff für jeden geeignet, der damit in einem bestimmten Projekt klar kommt.

Das alte Problem des Datenzugriffs – inzwischen gelöst

Aus historischer Sicht ist der Datenzugriff für Generationen von Entwicklern und Architekten ein großes Ärgernis gewesen. Es ist 25 Jahre her, als ich – noch als Student – das Konzept der relationalen Datenbank und einer strukturierten Sprache für das Formulieren von Abfragen begeistert begrüßt habe. Als ich später meine ersten richtigen Anwendungen schrieb, wünschte ich mir, etwas abstrakter als nur mit einer SQL-Syntax formulieren zu können. Doch bestenfalls war eine Menge von datenbankorientierten Objekten wie zum Beispiel connection, command und cursor zu bekommen. In der Mitte der 1990er Jahre tauchten einige O/RM-Lösungen auf, doch die .NET-Welt, in der ich zu tun hatte, kam mit dem ADO.NET-API heraus.

Das ADO.NET-API wurde einfach um eine Sammlung von datenbankorientierten Objekten aufgebaut: Verbindung, Parameter, Befehl, DataReader plus ein Bündel von speicherinternen Array-Objekten wie zum Beispiel DataSets, DataTables usw. Viele haben ADO.NET von Anfang an geliebt, andere haben sich mit der Zeit daran gewöhnt. Jahrelang war es das einzige Framework, das man von Microsoft bekommen konnte. Anspruchsvolle Programmierer gingen bald zu NHibernate über, doch war es am Anfang wahrscheinlich nur für einen sehr geringen Prozentanteil von Anwendungen lohnend. Es gab sogar Versuche, dies zu berechnen, doch ist meines Wissens der Anteil kaum über dürftige fünf Prozent hinausgegangen.

Anknüpfend an das reine ADO.NET-API brachten LINQ to SQL und dann das Entity Framework 4 einen wirklich leistungsfähigen Satz von Features mit einer Menge Designer und Werkzeuge, die die Verwendung beträchtlich vereinfachten. In der Zwischenzeit hat sich das Active-Record-Entwurfsmuster in der Ruby-Welt und um einige Open-Source-.NET-Frameworks wie Subsonic etabliert. Ich darf wohl sagen, dass es sich beim Datenzugriff um ein gelöstes Problem handelt.

In einer mehrschichtigen Anwendung ist es üblich, mit den Standardtools, die ein interessantes Kosten-/Nutzen-Verhältnis bieten, eine Datenzugriffsschicht zu realisieren, die Objekte dauerhaft speichert und abruft. Objekte werden nach dem Geschäftsbereich modelliert und bilden insgesamt ein Entitätsmodell mit feststehenden Beziehungen. Das Modell ist unabhängig von der physischen Speicherung und steht über eine Schicht von Diensten zur Verfügung, sofern es nicht ohnehin direkt für die Darstellungsschicht konzipiert ist.

Für eine „Quick-and-dirty“-Anwendung ohne Einschränkungen hinsichtlich der eigentlichen Datenspeicherung bietet LINQ to SQL in der .NET-Welt eine schnelle und effiziente Lösung, ohne dass man sich direkt mit SQL befassen muss und ohne das Risiko, Code einzubringen, der anfällig für SQL-Injection-Angriffe ist. Die Einarbeitungszeit für den Datenzugriff ist sehr kurz, da Sie lediglich die Datenbank organisieren und daraus ein ansprechendes und bequemes Entitätsmodell ableiten müssen – vergleichbar aber nicht identisch mit Active Record.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -