Datengebundene Webanwendungen mit AJAX.PRO

Zugriffe: 6975 starstarstarstarstarstarstarstarstarstar Bewertung:3,7 (10 Bewertungen) 24.07.2009

D37DUDTU3NH8

Immer wieder lese ich im Netz, dass Anwender sich schwer damit tun, AJAX.PRO in ihren Projekten einzusetzen. Dabei ist der Einstieg aus meiner Sicht bald noch einfacher, als wenn man das Ajax-Toolkit einsetzen möchte. Was braucht es dazu? Zum einem reicht es aus, wenn man der englischen Sprache mächtig ist, denn Michael Schwarz hat es zielgruppenorientiert eigentlich sehr gut auf seinen Webseiten dokumentiert.

Wer dem Englischen nicht so zugewandt ist, dem ist es ja freigestellt den nachfolgenden Ausführungen zu folgen.

1. Voraussetzungen

Als erstes sollte man sich die Ajax.Pro-Bibliothek aus dem Netz beschaffen. Diese ist mit und ohne Quellcode unter dem Portal codeplex hinterlegt und abrufbar. Hierbei sollte man wissen, dass die Weiterentwicklung durch Michael Schwarz abgeschlossen ist. Es steht jedoch jedem frei, die Bibliothek unter der Maßgabe der Lizenzvereinbarung weiter zu entwickeln. Nach dem Entpacken der Zip-Datei erhält man einen Ordner mit 4 verschiedenen Assemblies und einer Beispiel-web.config-Datei.

Ajaxpro Download

Der nächste Schritt ist dann die Einbindung in das eigene Webprojekt - dazu sollte eine Referenz auf eine Ajax.Pro-Bibliothek gesetzt werden.  

AjaxPro Reference AjaxPro Reference

Im Webprojekt wählt man dazu über das Contextmenü auf dem Knoten Reference den Eintrag Add Reference, so dass sich dann das Dialogfenster öffnet.

dll

Über den Register Browse navigiert man zu dem Verzeichnis, in dem man zuvor die Zip-Datei entpackt hat. Für eine .NET 1.x - Anwendung wählt man die AjaxPro.dll aus für alle anderen (also .NET 2.0 aufwärts) die AjaxPro.2.dll.

Hat man alles richtig gemacht, erscheint die Referenz unterhalb des Referenz-Knotens.AjaxPro Reference

Weiter muss die web.config-Datei erweitert werden, indem ein Http-Handler im system.web-Knoten hinzugefügt werden muss.

webconfig
webconfig

Dabei gilt es zu beachten, dass AjaxPro.2 nur dann anzugeben ist, wenn auch die entsprechende Assembly dazu eingebunden ist. Orientieren kann man sich hier sehr schön am Eintrag unterhalb des Knoten Reference.

Der nächste Schritt gilt der eigentlichen Client-Server-Kommunikation. In meiner praktischen Anwendung von Ajax.Pro hat es sich über die Jahre bewährt, hierfür dem Projekt eine separate Klasse hinzuzufügen. Dies hat vor allem den Vorteil, dass man alle Ajax-Server-Methoden zentral an einem Ort hat. Die Ajax-Methoden müssen dabei mit einem gesonderten Attribute versehen werden, so dass später klar ist, welche Methoden am Client verfügbar sein sollen. Der Klasse selbst kann man ebenfalls ein Attribut zuordnen, um so z.B. komplexere Namespaces kürzer zu fassen oder die Serverarchitektur am Client nicht völlig offen zu legen. Hilfreich ist weiterhin, über die using-Anweisung den AjaxPro-Namespace der Klasse hinzuzufügen.

namespacenamespace2

Der letzte Schritt ist dann die Registrierung der AjaxPro-Klasse für die eigentliche Verwendung am Client. Mit dieser Registrierung werden Javascriptobjekte erzeugt und in die Seite mit eigebunden, die es dem Anwender erst ermöglichen mit dem Server via Ajax.Pro(Javascript) zu kommunizieren. Für die Registrierung ist im Page_Load-Eventhandler der Seite der folgende Eintrag erforderlich:

registrierung

Der zweite Parameter in der Methode RegisterTypeForAjax ist optional, wobei es sich in der Praxis bewährt hat, ihn mit anzugeben. Bei der Verwendung von Masterpages erfolgt die Registrierung i.d.R. im Page_Load-Eventhandler der Masterpage.

Auf der Serverseite haben wir nun alle Voraussetzungen geschaffen, um auf der Anwendungsseite eine AJAX-Anwendung umsetzen zu können.

2. Anwendung

Wenden wir uns nun der clientseitigen Implementierung zu. Einer der vielen Vorteile von Ajax.Pro besteht darin, dass die eigentliche Lernkurve sehr gering ausfällt - das, was man in den serverseitigen Aufbau investiert hat, kann man eins zu eins auf der Clientseite wiederfinden. Die folgende Grafik soll dies verdeutlichen.

GetBenutzer

Auf der Serverseite wurde in dem Beispiel der Namespace auf Web.Server festgelegt (lila Markierung). Im Watchfenster kann man sehen, dass genau diese Objektstruktur am Client vorhanden ist. Die Ajaxmethode (grüne Markierung) ist ebenfalls unter gleichen Namen am Client wiederzufinden. Ein Blick auf den Rückgabetype der Ajaxmethode (orange Markierung) offenbart einen weiteren Vorteil von Ajax.Pro: man kann nahezu fast jedes .NET Objekt als Rückgabetype angeben. Ajax.Pro seriealisert diesen zum Client (und auch vom Client zum Server, wie weiter unten zu sehen), ohne dass man eine Zeile extra Code hierzu zu schreiben hat. Der Aufruf der Servermethode vom Client aus liefert immer ein Resultobjekt zurück. Die zwei wichtigsten Eigenschaften des Resultobjektes sind das error-Objekt und das value-Objekt. War der Aufruf am Server erfolgreich, also fehlerfrei, so ist das error-Objekt immer null. Das value-Objekt beinhaltet immer den Rückgabetyp der Servermethode. In der Grafik oben kann man sehr schön erkennen (orange Markierung), dass im Wege der Serialisierung die Eigenschaften des Objektes auch auf der Clientseite zur Verfügung stehen. Mit diesem Wissen ist man in der Lage, Ajax-Anwendungen zu erstellen, ohne dass es z.B. eines Updatepanels bedarf. Mit Ajax.Pro konzentriert sich der Entwickler auf das wesentliche einer Ajax-Anwendung, dem Datentransfer.

Ich habe zum besseren Verständnis ein kleines Beispielprojekt erstellt, in dem es darum geht, Daten aus einer Datenquelle auszulesen, am Client anzuzeigen, zu bearbeiten, Daten zu löschen und neue Daten hinzuzufügen. Im Wesentlichen sind dies die Standardaufgaben bei datengebundenen Webanwendungen - man möchte Daten lesen, bearbeiten, hinzufügen oder löschen. Wie einfach das ganze mit Ajax.Pro geht, möchte ich an Hand dieser Beispielsanwendung demonstrieren.

2.1 Die Datenquelle

Als Datenquelle habe ich eine einfache XML-Datei gewählt, wobei sich das Beispiel auch auf jede andere Datenquelle übertragen lässt. Der Aufbau der XML-Datei ist recht einfach gehalten: es gibt n-Benutzer Elemente, wobei jedes Benutzer-Element ein Attribute id besitzt und zwei weitere Childnodes, für Vorname und Nachname. über das mit dem .NET SDK bereitgestellte Tool xsd.exe habe ich noch eine passende .NET Klasse erzeugt. Wie sich die Klasse verwenden lässt, weiter unten im Text dann.

2.2 Das Javascript

Immer wieder lese ich in den Foren, dass Webentwickler zwar eine Ajax-Anwendung umsetzen möchten, Javascript aber auf der anderen Seite möglichst vermieden wird. Doch das JA im Wort AJAX steht für Javascript. Wie sieht die Implementierung für Ajax.Pro aus. Kommen wir noch mal zurück zu der vorangegangenen Grafik: der Namespace in der Ajax.Pro-Klasse findet sich auch auf der Clientseite wieder, ebenso wie die Methodennamen der Ajax-Methoden. Der Abruf einer Liste von Benutzern aus der Xml-Datenquelle sollte dann folgendermaßen aussehen:

client1

Über den onload-Eventhandler rufe ich die Methode GetBenutzerListe auf. Innerhalb dieser Methode findet die eigentliche Kommunikation mit dem Server statt, indem die Servermethode über Web.Server.GetBenutzerListe aufgerufen wird. Der Aufruf an sich gibt ein Resultobjekt zurück. Würde man so verfahren, dann hätten wir einen synchronen Serveraufruf. Damit der Aufruf letztendlich asynchron erfolgt, wird der Servermethode einfach der Callbackhandler mitgegeben. Der Callbackhandler ist dabei kein Methodenparameter im eigentlichen Sinne, sondern eine weitere Javascriptmethode. Diese wird immer dann aufgerufen, sobald die Kommunikation mit dem Server abgeschlossen ist. Das Resultobjekt ist dabei ein Methodenparameter des Callbackhandlers.

Das Resultobjekt hat wiederum weitere Eigenschaften, wobei die zunächst zwei wichtigsten das error-Objekt und das value-Objekt sind. Das error-Objekt sollte immer vorab auf null geprüft werden, bevor mit der eigentlichen Verarbeitung des Rückgabewertes begonnen wird. Wird ein konkretes Objekt in der Rückgabe erwartet, so hat es sich in der bisherigen Praxis bewährt, zusätzlich das value-Objekt ebenfalls auf null zu prüfen. Ist das error-Objekt nicht null, so sollte man sich Szenarien überlegen, wie man mit der weiteren Fehlerbehandlung am Client verfährt. Die Message-Eigenschaft des error-Objektes beinhaltet eine deatilierte Fehlermeldung, die der Exceptionmessage entspricht. Es ist selten zu empfehlen, die Fehlermeldung am Client direkt auszugeben - das sollte man sich gründlich überlegen.

In dem Beispiel wird eine Dropdownliste mit den vorhandenen Benutzern erstellt. Der Aufbau der Dropdownliste orientiert sich an allgemeinen Javascriptgrundlagen, wobei SELFHTML stets eine gute Quelle zum Nachschlagen bietet.

Nun, ich muss zugeben, bis hierher gab es noch keinen wirklichen Grund, für den Einsatz von Ajax.Pro, denn eine Dropdownliste kann man auch serverseitig an eine Datenquelle binden. Aber ich habe ja Eingangs geschrieben, dass ich zeigen möchte, wie man mit Ajax.Pro Daten anzeigen und bearbeiten kann.

Um nun die Benutzerdaten der Dropdownliste zu bearbeiten, versehen wir diese mit einem onchange-Eventhandler, der dafür Sorge tragen wird, dass das Miniformular

form

mit den entsprechenden Daten versehen wird. Auch hier könnte man den Einwand erheben, dass ja die Daten schon in der Dropdownliste vorhanden sind, doch soll hier mit diesem Beispiel die einfache Kommunikation mit dem Server demonstriert werden. Der Eventhandler der Dropdownliste führt dabei folgenden Code aus:

onchange

Der onchange-Eventhandler ist hier die Javascriptmethode GetBenutzer. über Web.Server.GetBenutzer (grüne Markierung) wird der Server aufgerufen. Als Parameter wird die ID des Benutzers erwartet (rote Markierung). Die Ajax-Methode GetBenutzer gibt dabei ein Objekt vom Type Benutzer an den Client zurück (pinkfarbene Markierung). Im Javascript wird wieder ein Callbackhandler (blaue Markierung) mit angegeben, der wieder aufgerufen wird, wenn der Server mit der Verarbeitung der Anfrage fertig ist. Auf der Serverseite wird die XML-Datenquelle geladen und genau das Element gesucht, das im id-Attribute-Wert dem übergebenen String entspricht. Hier habe ich die Benutzerklasse so gestaltet, dass wenn kein Benutzer in der Datenquelle gefunden wurde (weil z.B. ein anderer Anwender diesen zwischenzeitlich gelöscht hat), immer ein leeres Benutzerobjekt mit einer neuen Guid in der ID-Eigenschaft zurückgegeben wird. Diesen Umstand werden wir später noch gut zu verwenden wissen. Schaut man sich das Ganze mal in Ruhe an, so stellt man fest, dass immer der gleiche Ablauf erfolgt: der Client ruft den Server, der Server verarbeitet Daten und gibt eine bestimmte Information wieder an den Client zurück. Die gesamte Logik liegt dabei ausschließlich am Server. Was aber auch auffällt ist wieder das, was Ajax.Pro ausmacht: es wird kein Page-Lifecycle durchlaufen, sondern es werden nur die reinen Daten zwischen Client und Server ausgetauscht - ganz ohne Updatepanel.

Nachdem ich nun die Daten in das Formular geladen habe,

client2

möchte ich sie auch verändern und am Server wieder abspeichern können. Dazu erweitere ich das Formular um einen Button, der die Speicherfunktion über den onclick-Eventhandler aufruft.  Die o.g. Javascriptmethode WriteBenutzer habe ich inzwischen erweitert, um mir den aktuell ausgewählten Benutzer am Client zwischenzuspeichern, denn wie ich Eingangs schön erwähnte, kann ich mit Ajax.Pro .NET Objekte zwischen dem Server und dem Client in beiden Richtungen austauschen - diesen Umstand möchte ich beim Speichern des Benutzerobjektes gerne nutzen. Schauen wir uns den Code einmal an:

saveBenutzer

Inherhalb der Javascriptmethode SaveBenutzer übertrage ich die Formulardaten in das aktuelle Benutzerobjekt currentBenutzer. Im Anschluss wird die Ajaxmethode SaveBenutzer (rote Markierung) aufgerufen und das aktuelle (veränderte) Benutzerobjekt als Parameter (orange Markierung) mit übergeben. Ohne das es jetzt einer zusätzlichen Zeile Code bedarf, ist sofort eine Instanz der Klasse Benutzer mit den entsprechenden Daten am Server verfügbar. Somit braucht man nur noch die Save-Methode der Klasse Benutzer (blaue Markierung) aufrufen. An dieser Stelle könnte man jetzt die Werte noch validieren, wobei auch hier Ajax.Pro mir einen kleinen Teil der Validierung abnimmt: immer wenn die Wertzuweisungen vom Typ sich nicht übertragen lassen, wird eine Exception ausgelöst, was zu Folge hat, dass das error-Objekt im Resultobjekt nicht mehr null ist - die Anwendung auf der Clientseite bleibt nahezu unbetroffen; es bleibt Aufgabe des Entwicklers, das error-Objekt sinnvoll auszuwerten. Hat die Save-Methode der Benutzerklasse true zurückgegeben, so gibt die Ajaxmethode die aktuelle (veränderte) Liste an den Client zurück. Als Callbackhandler (lila Markierung) wurde WriteBenutzerListe angeben, mit der Folge, dass die Dropdownliste am Client sofort aktualisiert wird. Und wieder hat Ajax.Pro sich auf das Wesentliche beschränkt - dem reinen Datentransfer. Interessant ist in diesem Zusammenhang die Betrachtung, wenn statt der Liste null am Client ankommt - in diesem Fall wird die Dropdownliste nicht aktualisiert und am Client wird die Meldung ausgegeben, dass das Speichern fehlgeschlagen ist. Doch hierzu muss der Callbackhandler WriteBenutzerListe angepasst werden. Bevor ich dies tue, möchte ich das Resultobjekt noch einmal näher betrachten.

save-error

Neben dem error-Objekt und dem value-Objekt beinhaltet das Resultobjekt noch ein weiteres wichtiges Objekt - das request-Objekt mit den Eigenschaften args und method. Die method-Eigenschaft gibt Auskunft darüber, welche Servermethode aufgerufen wurde. Das args-Objekt beinhaltet alle an die Servermethode übergebene Parameter (Arguments). Mit diesem Hintergrundwissen kann der Callbackhandler WriteBenutzerListe nun angepasst werden.

saveerror1

Wenn also das value-Objekt null ist, obwohl ein Objekt erwartet wurde - nämlich die Benutzerliste - dann wird über die method-Eigenschaft des request-Objektes unterschieden, welche Meldung am Client auszugeben ist. Die Dropdownliste bleibt in diesem Fall unverändert, da ja die gewünschte Aktion am Server fehlgeschlagen ist.

saveerror2

Nicht viel anders verfährt man, will man einen Benutzer aus der Datenquelle löschen. Hierzu definiere ich wieder einen separaten Button, der mit einem onclick-Eventhandler versehen wird, welcher eine Javascriptmethode aufruft, die ihrerseits wieder eine Servermethode aufruft und dabei das zu löschende Benutzerobjekt an den Server übergibt und im Callbackeventhandler die Liste neu füllt. Auch hier wieder der Code im Detail:

delete

Die Javascriptmethode DeleteBenutzer stellt den onClick-Eventhandler des Löschen-Button dar. Als erstes wird das Infopanel gelöscht, da der Benutzer eine neue Aktion angestoßen hat. Dann wird die Servermethode DeleteBenutzer (orange Markierung) der Ajaxklasse aufgerufen, wobei das aktuelle Benutzerobjekt wieder an den Server mit übergeben wird. Vom Prinzip hätte an dieser Stelle auch ein String genügt, die ID des Benutzerobjektes. Als Callbackhandler (blaue Markierung) wurde wieder die Methode WriteBenutzerListe angegeben, da ja nach erfolgreicher Löschung des Benutzers die Liste wieder aktualisiert werden muss, weshalb auch der Rückgabewert des DeleteBenutzer-Methode wieder die Liste(Array) der Benutzer ist (grüne Markierung). Da ich das Benutzerobjekt wieder sofort am Server verfügbar habe, kann hier die Delete-Methode der Benutzerklasse aufgerufen werden (rote Markierung). Anders als beim Speichern, muss mit dem Rückgabewert null hier verfahren werden. Wenn Benutzer.Liste() null zurückgibt, dann ist die Liste leer. Daher habe ich mich hier der Vorzüge des error-Objekts bedient und einfach eine Exception ausgelöst (lila Markierung), wenn das Löschen am Server fehlschlägt. Auf der Clientseite übertrage ich dann einfach die Exceptionmessage in das Infopanel. Für den Fall, dass das value-Objekt null ist, muss sichergestellt sein, dass die Dropdownliste keine Einträge enthält. Dies erreicht man, indem man die length-Eigenschaft des option-Objektes auf 0 setzt.

Was habe ich bisher erreicht: ich habe auf der Serverseite schlanken überschaubaren Code, der vom Client direkt aufgerufen werden kann und ich habe auf der Clientseite Code, den ich mehrfach verwenden kann. Ich brauchte keine zig-Scripdateien zusätzlich einbinden, ich brauchte mich nicht darum zu kümmern, ob XMLRequest vom Browser überhaupt unterstützt wird, ich brauchte für die De-/Serialisierung der .NET-Objekte keine zusätzliche Zeile Code schreiben - ich habe mich in der Kommunikation zwischen dem Client und dem Server auf das Wesentliche beschränkt - dem Austausch von Daten. Ohne Updatepanel haben sich Teilbereiche meiner Seite verändert. Das grundsätzliche Vorgehen ist immer das gleiche - egal wie groß und komplex die Anwendung am Ende ist. Das ist es, was Ajax.Pro (und etwas Javascript) ausmacht.

Was in der Beispielanwendung noch fehlt, ist die Neuanlage eines Benutzers. Dabei ist die halbe Arbeit schon getan, ohne dass es uns dabei wirklich bewusst ist. Doch der Reihe nach.

Der Dropdownliste für die Anzeige der Benutzer wurde Eingangs ein onchange-Eventhandler zugewiesen. Dabei wurde die ID des Benutzers mit an den Server übergeben, in der Hoffnung, auch das entsprechende Benutzerobjekt vom Server zurück zu bekommen. Was ist aber, wenn kein Benutzer mit der übergebenen ID gefunden wurde? Aus diesem Grund hatte ich der Benutzerklasse zwei Konstruktoren spendiert, wobei der Standardkonstruktor eine neue Guid generiert und der id-Eigeneschaft zuweist und im übrigen alle weiteren Eigenschaften (Nachname, Vorname) einen Leerstring zuordnet. Der zweite Konstruktor ist mit dem id-Parameter ausgerüstet, um im Weiteren den Benutzer mit der übergebenen ID in der Datenquelle zu finden. Damit aber auch für den Fall, dass kein Benutzer in der Datenquelle gefunden wird, ein verwendbares Benutzerobjekt zurückgegeben wird, wurde sichergestellt, dass immer der Standardkonstruktor aufgerufen wird. Egal was passiert, es gibt immer ein Benutzerobjekt, das am Client weiter verarbeitet werden kann. Und genau diesen Umstand machen wir uns wieder zu nutze.

konstruktor

Also wird das Formular um einen Button zur Neuanlage eines Benutzers erweitert. Auch dieser Button wird mit einem onclick-Eventhandler ausgestattet, welcher über die Javascriptmethode AddBenutzer den Server aufruft. Damit bestehende Funktionalität genutzt werden kann, wird vorerst sichergestellt, dass die Dropdownlist auf den Index 0 gesetzt ist. Anschließend wird die Ajax-Servermethode GetBenutzer analog dem onchange-Eventhandler der Dropdownliste aufgerufen. Die übrige Vorgehensweise entspricht der des onchange-Eventhandlers. Da ich nun innerhalb des Callbackhandlers ein Formular erhalte, in dem nur die ID besetzt ist, kann ich die übrigen Felder ausfüllen und den Speichern-Button verwenden. Beim Speichen muss jedoch die serverseitige Ajax-Methode SaveBenutzer erweitert werden: Immer wenn das eigentliche Speichern des übergebenen Benutzerobjektes fehlschlägt, wird die Add-Methode der Benutzerklasse aufgerufen. Scheitert das Hinzufügen des Benutzers, so wird null zurückgegeben - in allen anderen Fällen die aktuelle Benutzerliste.

addBenutzer

Und damit wäre ich am Ende meines kleinen Beispiels. Was man aber deutlich sehen kann ist, dass man mit Ajax.Pro seine Anwendung im Sinne des MVC-Pattern aufbauen kann, ohne dass man viel zusätzlichen Code schreiben müsste. Einzig Disziplin wird dem Entwickler abverlangt bei der Einhaltung des Konzeptes: keine Logik am Client, so wenig wie nötig Programmcode in den Ajax-Servermethoden - dafür ist die Businessschicht da. Ajax.Pro konzentriert sich auf den Austausch von Daten zwischen Client und Server. Es werden nur die Methoden aufgerufen, die auch tatsächlich in der Client-Server-Kommunikation unmittelbar benötigt werden. Und Ajax.Pro nutzt JSON intensiv, so dass nahezu beliebige .NET-Objekte zwischen dem Client und dem Server in beiden Richtungen ausgetauscht werden können.

Michael Schwarz hält auf seiner Webseite zu Ajax.Pro noch viele weitere interessante Beispiele bereit. Dieser Beitrag sollte mal in etwas anderer Form einen kleinen Einstieg in Ajax.Pro vermitteln. Wenn es die Zeit erlaubt, möchte ich in folgenden Beiträgen noch weiter zu Ajax.Pro schreiben und vor allem Lösungsideen aufzeigen, die sich mit Ajax im Allgemeinen umsetzen lassen - ganz ohne Updatepanel.


7 Kommentare
Chris Cluss Chris Cluss Freitag, 24. Juli 2009
Wenn man Deinen ersten Satz liest:
>>Dabei ist der Einstieg aus meiner Sicht bald noch einfacher, als wenn man das Ajax-Toolkit einsetzen möchte.

und dann den Artikel überfliegt und die vielen Pfeile sieht, dann kommt man schon sehr ins schmunzeln ;-)

Auf den zweiten Blick aber eine sehr ausführliche und gute Erklärung von Dir.
Klasse!



Rene Rene Freitag, 24. Juli 2009
@Chris: die vielen Pfeile sollten in erster Linie verdeutlichen, dass die Lernkurve sehr gering ausfällt. Alles, was ich am Server habe, finde ich am Client wieder. Weiter sollten die Pfeile die Zusammenhänge der Methoden untereinander besser verdeutlichen.
Mario Mario Samstag, 25. Juli 2009
Sehr guter Artikel, danke Dir dafür!
Chris Cluss Chris Cluss Mittwoch, 29. Juli 2009
ja, ich weiß die vielen Pfeile auch zu schätzen.... manchmal geht der Schalk einfach mit mir durch.
Wie gesagt: Klasse.
Chris Cluss Chris Cluss Mittwoch, 29. Juli 2009
ja, ich weiß die vielen Pfeile auch zu schätzen.... manchmal geht der Schalk einfach mit mir durch.
Wie gesagt: Klasse.
Rainer Schuster Rainer Schuster Donnerstag, 17. September 2009
Hi Rene,

guter Artikel! Jetzt hab ich den Einsatz von Ajax.Pro auch mal verstanden
;-) ... spaß bei Seite. Was mir schon immer an deinem Code auffält, sind die stark verschachtelten if-else Blöcke. Ja, das hier ist nur ein Beispiel, aber ich weiß ja, das dein Produktivcode genau so aussieht.

Nehmen wir die Fehlerbehandlung des Results beim asynchronen EventHandler.

Warum testest du nicht lieber positiv auf einen Fehlerfall und damit einen early return anstatt deine Zweige stark zu verschateln. Das macht den Code etwas unleserlicher.

z.B.anstatt alles in WriteBenutzerListe zu "stopfen" trennst du die Funktion nach ihren verschiedenen Belangen. Du machst nähmlich 3 Sachen auf einmal.
Exception Handling, Error Handling (was ich eigentlich auch nicht für gut halte, das zu trennen. ein null value sollte zulässig sein.) und der eigentlich Teil, der funktionale, nämlich das schreiben der liste. Somit hast du 3 saubere Funktionen. Und du unternimmst nur den Versuch zu schreiben, da es ungewiss ist, ob die Funktion eine Exception wirf oder einen "erlaubten Fehler" zurückgibt, daher auch die Funktion tryWriteBenutzerList. Daraus ergibt sich neue, besser lesbare, selbstdokumentierende Struktur.

Was hälst du davon?

//...
WebServer.DeleteBenutzer(currentBenutzer, tryWriteBenutzerListe)
//...

function tryWriteBenutzerListe()
liste = $("BenutzerListe")
if (result.error != null)
//Exception!
handleException(result.error)
return

if (result.value == null)
//abhängig von der aufrufenden js-Funktion eine Fehlermeldung ausgeben
handleError(liste)
return

//funktionaler code folgt
WriteBenutzerListe(liste)
Dirk Matiack Dirk Matiack Montag, 14. Dezember 2009
Hallo Rene,

nach einigem googlen bin ich bei Dir hier gelandet und konnte meine Problemchen beim Portieren meiner Applikation von .NET1.1 auf .NET3.5 mit Deiner super Anleitung lösen :-) ... auch hier zieht langsam der Fortschritt ein ;-)

Vielen Dank, dass Du Dir diese Arbeit gemacht hast, und schöne Grüße,
Dirk

Neuen Kommentar verfassen

Bestätigungscode