Achtung: Polemik, Zuspitzung, Gemeinheit!
Das ASP.NET-Framework bietet diverse datengebundene Controls an, die der Visualisierung von Listen dienen. Die bekanntesten sind Repeater, DataGrid und GridView, gefolgt von einigen Exoten, etwa der DataList. Dazu gibt es wundervolle DataSource-Steuerelemente, die es erlauben, komplett ohne eine einzige Zeile an .NET-Code, Datenbanken an diese Steuerelemente zu binden.
Wenn man sich nun den Spaß macht, mal durch die Foren zu hirschen, dann bekommt man das kalte Grausen, denn die Kombination DataSource-Steuerelement + GridView-Steuerelement beherrscht seit .NET 2.0 quasi die Programmierung im ASP.NET-Umfeld. Was auch letztlich kein Wunder ist, denn sie sind idiotensicher einzusetzen und bringen Ergebnisse in wenigen Sekunden. Mit dabei sind dann gleich Features, wie etwa Paging und Sorting. Geil.
Nur leider ist es totaler Mumpitz und absoluter Schwachsinn, diese Controls extensiv und in Kombination miteinander einzusetzen. Denn sie räumen gründlich auf mit allem, was gemeinhin als Schichtentrennung, Wartbarkeit, Skalierbarkeit oder Qualität bekannt ist.
Die Gründe liegen auf der Hand:
Schichtentrennung ist nicht mehr gegeben, da der Code zum Abrufen von Daten – samt SQL-Statements! – speziell bei Verwendung vom SqlDataSource-Steuerelement in der WebForm selbst liegt. Statt also eine dedizierte Geschäftslogik damit zu beauftragen, Daten zu laden (zu cachen, aufzubereiten, zu analysieren, …), wird hier direkt auf die Datenquelle zugegriffen. Die komplette Verarbeitungslogik wandert dann in irgendwelche Ereignisbehandlungsmethoden im Code-Bereich der WebForm, statt in einer eigenen Verarbeitungsschicht zu liegen, wo sie ggf. auch gegen andere Implementierungen, Weiterentwicklungen oder sonstwas ausgetauscht werden könnte. Einzige akzeptierbare Ausnahme hier: Das ObjectDataSource-Steuerelement, das es erlaubt, gegen statische Methoden von Geschäftsobjekten zu arbeiten. Doof nur, dass mir dann dabei quasi vorgegeben wird, dass ich eben eine statische Methode brauche. Was ist mit meiner Factory (Provider, Builder, Broker, …), die ich ggf. habe?
Wartbarkeit? Gibts nicht mehr. Wie auch? Ein Beispiel: Es gibt zwanzig WebForms in einer Applikation, die auf diese Art arbeiten – also GridView + DataSource-Steuerelement. Jetzt wird das Datenmodell geändert, was im Rahmen von Weiterentwicklungen durchaus vorkommen soll. Das Ergebnis? Ich darf an mindestens zwanzig WebForms Änderungen vornehmen, statt es an nur einer Stelle in meiner Geschäfts- oder Datenlogik zu haben. Klasse. Nicht zu reden von der quasi nicht mehr vorhandenen Lesbarkeit des Codes. Neee, Wartbarkeit gibt es damit nicht.
Die Skalierbarkeit verschwindet ebenfalls hinter dem Horizont, denn ich habe schlicht keine brauchbare Möglichkeit mehr, in Datenhaltungs- und Caching-Prozesse einzugreifen. Geht nicht, ist ja alles inline. Klar, die SqlDataSource kann auch cachen – aber das kann ich im Code über das Application Data Caching viel zielgerichteter und genauer umsetzen. Wie also soll es skalieren? Zumal ich ja nicht mal in der Lage bin, einfach per Konfiguration etwa auf eine Web-Service-basierende Lösung umzustellen – ich müsste es halt überall ändern, wo ich auf die Daten zugreife. Oder eben eine andere Implementierung der Geschäfts- oder Datenhaltungslogik zu verwenden. Klar, es gibt die ObjectDataSource, aber… siehe oben. Dazu kommt: DataGrid und GridView sind zwar mächtig, aber eben auch langsam, denn die ganzen Funktionalitäten müssen ja irgendwo eingebunden werden. Auch, wenn man sie unter Umständen nicht benötigt. Und Tschüss, Skalierbarkeit!
Qualität? ROTFL! Wie denn, wo denn? Wie soll denn mit solch einem Gewurschtel, mit nicht mehr vorhandenen anerkannten Entwurfs- und Design-Patterns noch sowas wie Qualität erzeugt werden? Wenn man auch nur einen kurzen Moment mal nicht nur an die persönliche Bequemlichkeit denkt, dann muss man eigentlich zwangsläufig erkennen, dass man so ganz sicher alles baut, aber keine qualitativ hochwertige Software.
Die Lösung?
Back to the roots! Wenn datengebundene Listensteuerelemente, dann einen Repeater, keine komplett überdimensionierten GridViews und DataGrids. Und aus dem Code heraus die Daten binden. Kontrolle zurück gewinnen! Weiß denn eigentlich überhaupt noch jemand, wie man händisch die Daten binden lässt? Nein? Na, dann hier ein wenig Beispielcode:
protected override void OnPreRender(EventArgs e)
{
// Factory für den Business-Layer
BusinessLayer bl = BusinessLayer.GetInstance();
// Personen laden
IList
persons = bl.GetPersons();
// Personen binden
rptPersons.DataSource = persons;
// Datenbindung
DataBind();
}
Oh je, sieben Zeilen Code! Wie schrecklich!
Leute, seid mir nicht böse, aber von nix kommt auch nix. Sicher, ich spitze hier zu, aber Webseiten entwickeln hat eben tatsächlich was mit Entwicklung, mit Code, mit Abläufen, mit Architektur, mit Denken zu tun. Ihr müsst das nicht machen, keine Frage – aber genau so werden dann eure Ergebnisse aussehen: Zusammengestückelt, unprofessionell, langsam, nicht pflegbar. You get, what you pay for – kein Einsatz, kein Ergebnis.
Zu den Themen Paging, Sorting und Caching dann ein anderes Mal. Google hilft sicher bis dahin weiter – Stichworte: PagedDataSource, IComparer und Cache.
Update: Ihr wollt, dass man mal was über bestimmte Themen schreibt? Dann sagt es mir.
Comments(2)
