Friday, August 1, 2008

Dealing with .NET XMLSerializer

I've found that the clearest (e.g., fewest lines of code) and quickest (e.g., fewest surprises) way to deal with XMLSerializer is to create "data" classes. These instances of these classes are then owned and used by instances of "code" classes. This gets around the following issues:
  • XMLSerializer will only serialize Public fields. It isn't good programming practice to have to declare fields as public. To reduce this ugliness, I moved the serializable fields down into the data class and made the reference to the data class Private. I then put Public Property(s) on the code class that reference the field in the data class.
  • XMLSerializer doesn't support hashtables, which I find much more useful (and natural in many cases). I used hashtables on the code class. I then added code to a GetSerializable method that sits on the code class that populate the corresponding array on the data class on demand.
  • XMLSerializer doesn't provide very good error messages. My first attempt at changing a class to user XMLSerializer hit many problems with many different fields in the existing class. Using a data class, I don't have to figure out all the problems all at once. I can move fields from the code class to the data class incrementally, and figure out the particular problem with that field before moving on to the next. One specific example of this are issues with using Public Property. I haven't figured out what they are yet, but I'm suspicious of either:
  • Public Properties that aren't simple "return" and "assignment" Properties.
  • Public Properties that wrap a field that is also Public.

The downside is that I have a few extra public fields on various objects that are only used for serialization. The upside is fewer lines of code and a (somewhat) straightforward paradigm for dealing with XMLSerializer.

No comments: