I had a similar problem to solve, which I did by creating an
XML-serializable base class from which all of the types are derived. Note
that this is slightly different from your problem in that I do not parse an
XmlDocument instance, but de-serialize a class from an XML file that is a
serialized instance of a derived class). The base class can be used to do
the de-serialization without knowing the derived type.
The tricky part is that there must be a
System.Xml.Serializatiion.XmlIncludeAttribute Attribute in the base class
for each derived class. The System.Xml.Serialization.Serializer instance
used to deserialize the class instance must have information about the extra
members of the derived class in order to be able to deserialize it. Of
course, the problem is that the class may be extended with additional
derived types in the future. Due to time limitations I simply add a new
System.Xml.Serializatiion.XmlIncludeAttribute Attribute to the base class
whenever I create a derived class from it. Of course, this is not the best
solution, but the best solution, which is entirely doable, is a bit
complicated to implement. I plan to do this someday, but for now, in case
you want to, I will give you an overview of how it would be done.
It would be done using the System.Reflection and System.Reflection.Emit
namespaces. As any derived type being deserialized would be in a loaded
assembly, using the System.Reflection namespace classes, one could discover
all of the derived types in all loaded assemblies at run time. One could
also discover any System.Xml.Serializatiion.XmlIncludeAttribute Attributes
that already exist in the base class. Then, using the
System.Reflection.Emit.TypeBuilder and
System.Reflection.Emit.CustomAttributeBuilder classes, the necessary extra
derived class Attributes could be added to the base class type at run-time.
Once the class is de-serialized, it is a simple matter to determine the
derived type of the instance that was created by the Serializer.
--
HTH,
Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com
A watched clock never boils.
"Angel Of Death" <af***@23o.1f.co.ukwrote in message
news:ef***********@custnews.inweb.co.uk...
>I have a method. It takes some XML as a parameter. Depending on the
content of the XML it should create a specific object and call a KNOWN
method.
So: public void PersistXml(string XmlData){}
I then determine what object I should call the Persist method on using a
switch statement (not very OO).
switch (otype)
{
case "type1"
switch (osubtype)
{
case "subtype1"
//create type
foo x = new foo();
x.Persist();
break;
case "subtype2"
foo2 x = new foo2();
x.Persist()
break;
}
case "..."
foo3 x = new foo3()
x.Persist();
break;
}
I can see from here that I really just have one method (Persist) and
that all I'm really doing is creating the right object at run-time and
then calling a known method on it.
I was thinking that perhaps I could create the objects at runtime and
use an interface for the known method to then call it:
object o = Activator.CreateInstance(type);
IPersist persist = o as IPersist; //IPersist is same sig as PersistXml
if (persist != null)
{
persist.Persist(XmlData);
}
But being a novice I'm not really sure if there is a better way (or if
there are even issues with implementing it this way). It seems to me
that I shouldn't be worried with what object should be created, and that
I should be able to have the correct Persist method called for me using
Polymorphic code, yet if I have to create the subtype then I surely need
to know its type? I could use virtual methods and overrides but this
doesn't help me with the object creation and if I need to know the
subtype to create it, then I dont need polymorphic behaviour since I can
just call the method on it directly since I will have a reference to the
specific object.
What's the cleanest way to implement this. Either way the switch
statement has to go! :-)
