RemObjects SDK for .Net > XML Serializer und Databinding

[Phoenix]

Zitat von jensw_2000:

Unter dem Strich will ich in meinem Asp.Net Client einfach nur ein Objekt vom Webservice abrufen und für das Databinding nutzen. Das Abrufen klappt. Das Databinding nicht.

Uh, im weiteren Text kommen böse Wörter wie 'Data Source' vor

Ich würde erstmal empfehlen Dir ASP.NET MVC anzugucken. Da ist die Sache mit dem Daten ans UI bringen massivst einfacher, und Du hast viel mehr Kontrolle über das, was da 'vorne' passiert. ASP.NET WebForms ist zwar cool (zumindest sieht das auf den ersten Blick so aus), aber man braucht richtig viel Zeit um das Framework so weit zu verstehen, das man nicht mehr in typische Fehler läuft.

Das Nutzen von Datasourcen ist so ein typischer Fehler, denn das Web funktioniert nunmal Protokollbedingt *komplett* anders wie eine Desktop-Applikation (im Web ist man Stateless, Desktop-Anwendungen behalten ihren Status zwischen Benutzeraktionen), und insbesondere Datasourcen sind da konzeptbedingt so dermasse 'falsch', dass sie auf mittlere bis lange Sicht *nur* Probleme machen. Der Ansatz ein Objekt das in der Regel schon als XML über einen Webservice kommt und dann erst in ein Objekt deserialisiert wird dann wieder zurück in XML zu serialisieren ist auch, sagen wir mal 'mutig' - sowohl aus Architektur als auch aus Performance-Sicht.

Wenn Du unbedingt bei WebForms bleiben willst und kein MVC nutzen kannst (was extrem schade wäre), kann ich Dir aus jahrelanger Erfahrung mit ASP.NET folgende Tipps geben:
Finger weg von ASPX- und ASCX-Files. Erzeuge Controls von Hand indem Du CreateChildControls auf den Pages bzw. Controls überschreibst, und fülle die Controls von Hand mit den Daten. Schreibe Controls ohne ASCX sondern ausschliesslich im Code. Lese die Daten von Hand aus, validiere jede einzelne Benutzereingabe (das machen die Datasourcen sowieso unmöglich, und das validieren von Benutzereingaben im Web ist unerlässlich), und verarbeite sie dann. Das ist zwar etwas mehr Code, erlaubt aber mehr Kontrolle als aspx-files, bei denen man sich nie sicher sein kann welche Controls bereits wann erzeugt wurden, weil zum Teil bei Postbacks nur bestimmte Teile des 'Control Tree's' erzeugt werden die unbedingt nötig sind um die Lifecycle-Events zu triggern. Der Rest kommt dann erst viel später, und ggf. sind Controls noch gar nicht erzeugt wenn man auf sie zugreifen will und haben selbst wenn man sie dann explizit erzeugt konsequenterweise auch noch keine Daten, da das passende Event hier auch erst viel später kommt.

Das ganze mag zwar sehr aufwändig klingen, erspart aber ein klein wenig später massiv Arbeit.