Object created by XML-deserialization?

[Ruben]

Hi!

Is there a way to figure out, if the constructor or the Set-methods of
fields are called by the XML-deserilization or by other calls?

I would like to bind special behaviour to my class when those methods
are called by the deserializer...

Thank you!
Ruben

 

[Marc Gravell]

You may be better off explicitely calling a self-defined
post-deserialization fix-up method; the xml-serializer does not support the
same level of flexibility as the binary serializer ("events" [attributed
methods], callback interfaces, etc), so without implementing
IXmlSerializable it can be a real pain.

Marc

 

[Marc Gravell]

For completeness, see examples here:

http://msdn2.microsoft.com/en-us/library/system.xml.serialization.ixmlserializable.aspx

Marc

 

[Martin Z]

Hi!

Is there a way to figure out, if the constructor or the Set-methods of
fields are called by the XML-deserilization or by other calls?

I would like to bind special behaviour to my class when those methods
are called by the deserializer...

Thank you!
Ruben

The XMLSerializer is very limited - all it does is call the
parameterless constructor and use the property-setters.

In general, when making classes for the XML-serializer, the best thing
to do is to pretend you're back in school, doing your stupid "my first
OOP app" style of code. No collections other than arrays (support for
other collections has some gotchas), no interfaces, avoid custom
generics, avoid events, and in general avoid anything clever. Then,
stuff XmlInclude on any base-classes to forward-declare the existence
of subclasses in cases where a member (or array) is being used in a
polymorphic manner. Deviating from these rules will get the Xml type
system confused.

 

[ssamuel]

On the contrary, nothing in the set of interfaces, generics, events,
and other "clever" stuff is ruled out by XML serialization and
deserialization using IXmlSerializable. Once you get the hang of
writing ReadXml() and WriteXml(), it's very straightforward.

It's completely valid to have a generic data structure with a variable
number of elements; this should serialize very nicely -- you'll have to
use foreach in WriteXml() -- and you can pile them back into the
generic in ReadXml(). As for non-data structure generics, it depends
completely on what your generic does, but a quick mental scan can't
come up with anything definite that wouldn't serialize.

What interfaces you implement is completely irrelevant in XML
serialization. I've written classes that deserialize abstract classes
or interface references. It takes a bit of reflection, but I've found
the performance hit to be very manageable. Yes, you need a non-derived
wrapper class for stuff that may be derived, but I've always found a
natural way to work this into my object model.

Keep in mind that you're in complete control over what gets serialized
and how. Given the proper XML attribute decoration, you can come up
with a way to describe just about anything well enough to be able to
deserialize it.


Stephan

 

[Martin Z]

I meant how to support the Serializer without manually doing it's job
using IXmlSerializable. I've always preferred using native utilities
rather than rolling-my-own, personally... but in this case the native
utility is quite limited, so it's a decision that's up to the designer
- if you're willing to follow my rules, you don't need to implement the
interface. If you need more expressiveness, then you use
IXmlSerializable.