P
Peter Duniho
I've been learning about mechanisms .NET offers to export data. The
initial goal is to see what sorts of ways are available to save an
application's state (document, internal database, whatever). Not counting
storing data in a database (which is obviously suitable for some things,
but not necessary or even necessarily desirable for other things), here's
what I've explored:
Serializable attribute, with BinaryFormatter and SoapFormatter
Implement IXmlSerializable
The methods based on Serializable are in fact fairly easy, but they don't
produce output that would be readily usable in other applications. What I
like about it is that with some pretty simple and brief code, one can
easily serialize whatever data in the class one wants (and for some very
basic classes, you don't even have to write code). I only had to write a
half-dozen lines of code specific to the serialization, and that only
because my top-level data structure is a generic collection, which isn't
supported implicitly.
It was no surprise to me that the output using BinaryFormatter isn't
readily importable into other applications, but I had higher hopes for
SoapFormatter. Probably because I know so little about SOAP, but I was
hoping that with it being based on XML, it would generate an XML document
that I could load into, for example, Excel and have it readily understand
it (the data I'm dealing here is essentially a list of items, and I want
to be able to read the list into Excel with one item per row, each field
in its own column).
Instead, the SoapFormatter creates all these links within the document,
with sections corresponding to each data type, among other things. Excel
can, of course, read the document but because it doesn't have a
traditional tree-based layout, it doesn't really import the data in a
useful way.
Since I wanted the XML document to be organized more like the original
list the data is in, I looked at implementing IXmlSerializable. Not that
this was all that hard either, but I did find that I had to write a _lot_
more code, because there's nothing in the XML serializing stuff that
automatically deals with non-public fields in a class. I don't want
writable properties on my classes and the XmlSerializer.Serialize() docs
say that it will only serialize public members.
As it was, I had to make what are really internal classes public, because
the auto-generated assemblies need access to the types (as near as I can
tell, this is solely because of the need to construct the relevant
object...seems like if they'd added some sort of static object
construction method to IXmlSerializable, this need could be avoided in a
lot of cases, but they didn't so it's not
).
So, now I have a bunch of code, which is what looks to me to probably be
about 90% of what I'd have to write if I just did all the XML
serialization explicitly, without even using the XmlSerializer class. And
it required that I expose parts of my assembly that really don't need to
be exposed, by making the classes public.
I'm curious as to whether there are other methods of saving data that I've
overlooked. I noticed that there's WAY more stuff in the
Xml.Serialization namespace than I've actually used. I've barely
scratched the surface. But the docs seem pretty explicit about the fact
that it won't automatically handle non-public members, so I don't really
know what all that other stuff might do for me.
Am I really best off just doing this all explicitly and forgetting the
built-in serialization classes? Because of the more general-purpose XML
support, doing that isn't really all that hard, but I'm curious if that's
really the best way to go.
Thanks for any advice,
Pete
initial goal is to see what sorts of ways are available to save an
application's state (document, internal database, whatever). Not counting
storing data in a database (which is obviously suitable for some things,
but not necessary or even necessarily desirable for other things), here's
what I've explored:
Serializable attribute, with BinaryFormatter and SoapFormatter
Implement IXmlSerializable
The methods based on Serializable are in fact fairly easy, but they don't
produce output that would be readily usable in other applications. What I
like about it is that with some pretty simple and brief code, one can
easily serialize whatever data in the class one wants (and for some very
basic classes, you don't even have to write code). I only had to write a
half-dozen lines of code specific to the serialization, and that only
because my top-level data structure is a generic collection, which isn't
supported implicitly.
It was no surprise to me that the output using BinaryFormatter isn't
readily importable into other applications, but I had higher hopes for
SoapFormatter. Probably because I know so little about SOAP, but I was
hoping that with it being based on XML, it would generate an XML document
that I could load into, for example, Excel and have it readily understand
it (the data I'm dealing here is essentially a list of items, and I want
to be able to read the list into Excel with one item per row, each field
in its own column).
Instead, the SoapFormatter creates all these links within the document,
with sections corresponding to each data type, among other things. Excel
can, of course, read the document but because it doesn't have a
traditional tree-based layout, it doesn't really import the data in a
useful way.
Since I wanted the XML document to be organized more like the original
list the data is in, I looked at implementing IXmlSerializable. Not that
this was all that hard either, but I did find that I had to write a _lot_
more code, because there's nothing in the XML serializing stuff that
automatically deals with non-public fields in a class. I don't want
writable properties on my classes and the XmlSerializer.Serialize() docs
say that it will only serialize public members.
As it was, I had to make what are really internal classes public, because
the auto-generated assemblies need access to the types (as near as I can
tell, this is solely because of the need to construct the relevant
object...seems like if they'd added some sort of static object
construction method to IXmlSerializable, this need could be avoided in a
lot of cases, but they didn't so it's not
).So, now I have a bunch of code, which is what looks to me to probably be
about 90% of what I'd have to write if I just did all the XML
serialization explicitly, without even using the XmlSerializer class. And
it required that I expose parts of my assembly that really don't need to
be exposed, by making the classes public.
I'm curious as to whether there are other methods of saving data that I've
overlooked. I noticed that there's WAY more stuff in the
Xml.Serialization namespace than I've actually used. I've barely
scratched the surface. But the docs seem pretty explicit about the fact
that it won't automatically handle non-public members, so I don't really
know what all that other stuff might do for me.
Am I really best off just doing this all explicitly and forgetting the
built-in serialization classes? Because of the more general-purpose XML
support, doing that isn't really all that hard, but I'm curious if that's
really the best way to go.
Thanks for any advice,
Pete
