RemObjects SDK for .Net > XML Serializer und Databinding

[jensw_2000]

Hi,

ich "plage" mich gerade mit dem Erlernen von .Net und der Oxygene Language herum.
Bin da noch recht grün hinter den Ohren. Also nicht beißen, falls die Fragen zu dumm sind

Also:

Ich habe eine Delphi Anwendung in der ein XMLRPC Webservice läuft (über das RemObjects SDK).
Wenn ich in meinem Delphi Client ein Objekt von dem Webservice abrufe und dies serialisieren möchte, dann hat das RO SDK da eine super Funktionen für >> ObjectToXML.

Sowas will ich auch mit Prism XE2 und dem "RemObjects SDK for .Net" haben.
Die im Wiki dokomentierte Serializer Klasse verstehe ich ohne Beispielcode und Beschreibung noch nicht..

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.

Ich habe die ObjectDatasource "entdeckt" mit der man Objekte über eine Art "Wrapper Class" databinden kann. Das will ich aber nicht machen, denn mit der Wrapper Class würde ich mir doch eine zweite Schicht erzeugen, an der ich die Klassendefinitionen pflegen und warten muss. Oder?

Deshalb glaube ich, das es praktischer wäre das "live abgerufene" Objekt als XML zu serialisieren und einfach eine XML Datasource zu nutzen.

Und da drehe ich mich im Kreis.
Was ist im RO SDK for .Net das Äquivalent zur Funktion ObjectToXML des RO SDKs für Delphi?

Oder bin ich komplett auf dem Holzweg ...?


Kann mir jemand auf die Sprünge helfen?


Grüße
Jens

[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.

[jensw_2000]

Hi Phoenix,

mir ist gerade erst eben aufgefallenen, das Du ein Mann vom Fach bist ...

Zitat:

[RemObjects Software]

MVC funktioniert auf Grund irgendwelcher Einschränkungen von VisualStudio Shell 2010 in Prism XE2 nicht mehr.

Du meinst also, es wäre *absolut falsch* zur Komponentenpalette zu greifen und sich ein paar Controls auf die ASPX Site zu klicken und das man besser alle Servercontrols selbst entwickeln und rendern sollte?

Das war eigentlich ein wichtiger Gund für mich, von PHP abzurücken und mich mit ASP.Net zu beschäftigen (und die native Nutzung der RO SDK Binary Message sowie die "abgespeckte DevExpress ASPxperience Suite" die bei meiner VCL Subscription mit dabei ist ).

Das klingt alles übel

Ich habe ganz zum Anfang zur Übing mal ein "simples" RenderedControl gelastelt. Das hat bei mir 3-4 Tage gedauert und ... war nur eine TeaserBox mit Header einem "Read more Link" und ein paar Properties.

Wäre es eine Alternative, wenn ich statt der XML DataSource doch eine Wrapper Class für eine ObjektDatasource baue? Da könnte ich im Setter ja noch mal prüfen, was ich in das Objekt zurückschreibe.

Vorhin habe ich im "RemObjects Connect" erfahren, dass beim SDK for .Net auch kein XMLSerializer mit dabei ist. Da bleibt mir vermutlich wirklich nur der harte Weg und alles selber rendern oder die ObjectDataSource als Alternative.

Wie würde das Ganze bei MVC weitergehen, nachdem ich die Daten über ClientChannel und Bin-Message vom Webservice abgeholt habe?

Eventuell muss dann noch ein VisualStudio Lizenz her ...



PS: OK, ich habe mir in den letzten 2,5 Stunden MVC Tutorials auf Youtube und bei DevExpress angesehen.
Sieht interessant aus, aber ... damit befasse ich mich erst in 2012.
Die Version 1 meiner ASP.Net UIs für meine beiden Webservices wird WebForms basiert.


Danke Dir erstmal.

Grüße
Jens