[C#] Class serializen als string-element

[_Thanatos_]

Het komt er een beetje op neer dat ik een heel simpel classje heb, met twee properties die geserialiseerd moeten worden. De ene property moet een attribuut van het element worden en de andere moet de textnode van het element worden.

Dit is het classje:

C#:

public sealed class FieldData {
    [XmlAttribute] public string Name;
    [XmlElement] public string Value;

    public FieldData() { }

    public FieldData(string Name, string Value) {
        this.Name = Name;
        this.Value = Value;
    }

    public override string ToString() {
        return Value;
    }
}

Pretty simple huh
Die Value property moet dus de textnode van het geserialiseerde element <FieldData> worden, maar dat krijg ik niet voor mekaar. Voor de duidelijkheid, zo moet ie dus worden:

code:

<FieldData Name="naampje">waarde</FieldData>

En de extra moeilijkheid die hierbij komt kijken is misschien dat het voor een SOAP webservice ook zo moet werken. Ik geef een array van dit objectje in een webmethode terug en het moet dus in de SOAP-response zoals hierboven uitgepoept worden.

Maargoed, ik krijg het dus niet voor elkaar. Ik heb al wat lopen rommelen met de attributen XmlText, XmlRoot, ik heb al een aantal voorbeeldjes opgezocht, maar eigenlijk niks dat laat zien hoe het moet wat ik wil... wie helpt me verder?

[bigbeng]

Ik kan me vergissen, maar dit is toch geen serialization? Hoe dan ook, het is wel XML en dat kun je dus ook over SOAP gebruiken.

[ Voor 39% gewijzigd door bigbeng op 06-01-2006 13:04 ]

[_Thanatos_]

Maar hoe dan

[elmer25]

Waarom ga je zelf SOAP messages maken? .NET heeft alles aan boord om webservices te maken en gebruiken zonder dat je maar 1 regel XML hoeft te zien.

[Not Pingu]

TS: al de XmlSerializer class gebruikt?

[_Thanatos_]

elmer25, ik ga niet zelf SOAP messages maken, ik wil dat de SOAP-messages die gegenereerd worden, gegenereerd worden zoals ik dat wil.

Gunp01nt, nog niet, omdat ik een beetje het idee heb dat je daarmee niet de WSDL overeen laat komen met wat er geserialiseerd wordt. Kun je misschien bevestigen of dat zo is, of niet?

[ Voor 3% gewijzigd door _Thanatos_ op 06-01-2006 17:41 ]

[Verwijderd]

Je kan een class toch 'serializable' maken door er het gelijknamige attribuut boven te knallen?

[Not Pingu]

_Thanatos_ schreef op vrijdag 06 januari 2006 @ 17:41:
Gunp01nt, nog niet, omdat ik een beetje het idee heb dat je daarmee niet de WSDL overeen laat komen met wat er geserialiseerd wordt. Kun je misschien bevestigen of dat zo is, of niet?

Als ik je vraag goed begrijp, dan wil je het object zowel zelf serializen als dit in een Webservice laten doen?
Sowieso is het in dat laatste geval niet mogelijk om je output te 'sturen' omdat het dan altijd afwijkt van de WSDL spec die ASP.NET automatisch genereert. De webservice houdt alles nl. zelf in de hand. Maar bij mijn weten gebruiken ASP.NET webservices ook de XmlSerialzer dus de output zou gelijk moeten zijn. Dit kun je natuurlijk makkelijk testen.

[ Voor 5% gewijzigd door Not Pingu op 06-01-2006 19:40 ]

[EfBe]

IXmlSerializable implementeren.

[whoami]

EfBe schreef op zaterdag 07 januari 2006 @ 11:09:
IXmlSerializable implementeren.

Wat is het verschil met ISerializable ?
Het enige wat ik in de doc's kan terugvinden over IXmlSerializable is

This type supports the .NET Framework infrastructure and is not intended to be used directly from your code.

[EfBe]

whoami schreef op Saturday 07 January 2006 @ 11:43:
[...]
Wat is het verschil met ISerializable ?

dag en nacht
Zoals je hier ook al ziet is er een grote verwarring gaande:
1) serializing mbv formatters voor remoting: binary/soap of je eigen. Hiervoor gebruik je [Serializable] en ISerializable.
2) serializing naar XML, al dan niet voor webservices. Dit is iets totaal anders en hiervoor wordt IXmlSerializable gebruikt voor customization en/of attributes op de properties (!) en dit wordt verzorgd door de XmlSerializer.

De TS wil 2) en dus is alles wat te maken heeft met 1) niet aan de orde.

Het enige wat ik in de doc's kan terugvinden over IXmlSerializable is
[...]

Dat is in .NET 1.x. IXmlSerializable is hidden gemaakt omdat de wsdl.exe tool hardcoded besluit dat wanneer een class IXmlSerializable implementeert het DUS een dataset is. In .NET 2.0 kun je dit sturen mbv extra attributes en kun je dus bij:
[WebMethod]
public CustomerEntity GetCustomer(int customerID)
{
//..
}

ervoor zorgen dat de door wsdl.exe gegenereerde stubs niet een 'dataset' verwachten voor GetCustomer maar CustomerEntity, wanneer je IXmlSerializable implementeert in CustomerEntity.

Er is nauwelijks documentatie over, althans tot voor kort iig, en echt vrolijk wordt er niet niet van, maar dat is inherent aan webservices, want een webmethod kan nog altijd niet polymorphed verschillende types returnen: als ik in bovenstaande method een SpecialCustomerEntity return wat een subclass is van CustomerEntity, krijg ik t.a.t. een CustomerEntity instance terug en nooit een SpecialCustomerEntity instance. Om over generics nog maar te zwijgen.

IXmlSerializable implementeren hoeft lang niet altijd, je kunt ook mbv attributes op de properties (en niet op public fields) aangeven hoe iets moet worden geserialized. De webservice core gebruikt gewoon XmlSerializer om een object te serializen naar XML en prakt de output daarvan in de Xml stream die naar de client wordt gestuurd. Dat doe je eigenlijk dus ook in je IXmlSerializable implementatie.

Je moet soms IXmlSerializable implementeren omdat de XmlSerializer een retarted class is die bv niet overweg kan met dictionaries en cyclic references, en dat terwijl de soap formatter dat bv prima kan. De soap formatter is overigens deprecated, want deze is niet meer geupdate voor generics.

Dus, het komt neer op 2 dingen:
1) wanneer object graphs worden verstuurd, maak het je makkelijk en gebruik remoting en de binary formatter.
2) wanneer je toch webservices wilt, gebruik dan messages ipv object graphs. Messages gebruiken vereisen een andere opzet van je architectuur maar verzorgen wel voor veel meer performance en ook dat de services makkelijker te designen zijn, omdat je op een hoger abstractieniveau moet gaan zitten dan bij object graph consuming services.