In meinem letzten Artikel UserControls mit Properties/Konstruktoren dynamisch laden (Server und Client) habe ich dargestellt, mit welch relativ geringem Aufwand man komplexe ASP.NET-Steuerelemente auch per Javascript über einen WebService in eine Seite injizieren kann. Es geht aber noch besser...

Das Update

Mein Javascript-Code ist, für die mehrmalige Verwendung innerhalb eines Projekts, schon ein ziemlicher Brocken (20-30 Zeilen, ja nachdem wie leserlich man es haben möchte) und so drängt sich ein Refactoring quasi schon auf. Grund dafür ist natürlich der recht umfangreiche AJAX-Aufruf mittels jQuery.

Zudem fiel mir auf, dass ich einen inhaltlichen Fehler begangen habe. In der Javascript-Methode getElementHtml wird im Erfolgfall das Element direkt an den Container gehängt, was man bei dem gewählten Methodennamen nicht direkt erwarten würde. Shame on me...

Um nun die Routine zu entzerren und allgemeingültiger zu halten, habe ich ihr zwei weitere Eingabeargumente namens successFunction und errorFunction verpasst, die definieren was im Erfolgs- bzw. Fehlerfall passieren soll.

UserControls sind herrlich, um Code-Redundanzen zu vermeiden. Wiederkehrenden HTML-Code lagert man in ein solches Benutzersteuelement aus und etwaige Änderungen müssen nur einmal an zentraler Stelle vorgenommen werden.

Programmatisch ein solches Steuerelement in die zu rendernde Seite einzufügen, ist hingegen nicht ganz so trivial. Vor allem, wenn man dem Control eine oder mehrere Eigenschaften verpasst hat, die den Inhalt oder das Aussehen steuern, oder wenn man gar einen Konstrukor mit Argumenten geschrieben hat. Aber ... wie immer gibt es einen Weg, bzw. mehrere, die ich hier aufzeigen möchte.

Zugriffe auf Datenbanken wie SQL-Server oder andere, sollten in jeder Anwendung aufs Nötigste beschränkt werden. Um ein paar Daten zum Beispiel auf eine WebForm zu bringen 3, 4 mal die Datenbank zu konsultieren, bis man alle Daten zusammen hat, ist ineffizient und bedeutet Perfomance-Verlust.

Bei der Anzeige hierarchisch strukturierter Daten wird dieser mehrfache Zugriff jedoch oft in Kauf genommen, um die einzelnen Ebenen getrennt voneinander verarbeiten zu können. In Zeiten von LINQ ist dies eigentlich unnötig, da man hier Daten auch gruppieren kann. Jedoch gibt es auch Alternativen, wenn zum Beispiel der Web-Provider das .NET-Framework 3.5 noch nicht unterstützt oder man die Einarbeitungszeit in LINQ scheut. Auch können LINQ-Statements mit 5 oder 6 Ebenen extrem unübersichtlich werden und somit die Wartbarkeit des Codes verschlechtern.

Die Micosoft Message Queue ist eine feine Sache zur asynchronen Verarbeitung von Daten. Die .NET-Implementierung im Namensraum System.Messaging kennt dabei zwei hauptsächtliche Objekte: MessageQueue und Message. Ersteres muss man öffnen, um letzteres absetzen zu können.

Die Nachrichten, die eine Message beinhalten kann, werden über sog. Formatter in ein für die Gegenstelle lesbares Format gebracht. In .NET ist der Standard-Formatter der XmlMessageFormatter, der beliebige, serialisierbare Objekte in XML und dann in ein Stream-Objekt umsetzt, dass an die Message-Queue verschickt wird.

Ich persönlich empfinde Erweiterungsmethoden, die mit C# 3.0 bzw. VB.NET 9.0 eingeführt wurden, als eine große Bereicherung im täglichen Kampf mit dem eigenen Code. Wo man früher meist eine Klasse namens Tools oder ähnliches hatte, in der kleine Genralwerkzeuge untergebracht wurden, die Microsoft in der Eile vergessen hatte in die Sprache einzubauen, erweitert man heute einfach den benötigten Datentyp und gut.

Hat man zum Beispiel irgendwo einen String, der eigentlich keiner ist, sondern ein Zahl kann man folgende Routine auf ihn loslassen und dann damit weiterrechnen:

	Dim intValue As Integer = Convert(strValue, Integer)
	intSum = intValue + 2
	...

Oder man schreibt sich eine kleine Erweiterungsmethode namens ToInt und bohrt damit den String-Datentyp auf, sodass von obigem Beispiel im Endeffekt nur folgendes übrig bleibt:

	intSum = strValue.ToInt + 2

Ich selbst habe mir schon eine Handvoll solcher Extensions geschrieben und möchte sie nicht mehr missen. Microsoft selbst hat diese Technik auch ganz besonders lieb, basiert doch LINQ in all seinen Farben, Formen und Variationen darauf.