C# Serialization

Michael O Donnell

Hi

This is more a question on best practices rather that a specific problem with Serialization. I've created a Person class with forename, surname, dob, mobile, email global variables and I've declared these variables as private. I've then added a property for each of the global variables so I can read them and update them as necessary. I've also create a function that calculates a persons age based on the current year and the year element from the dob variable.

I want to be able to serialize and deserialize my Person class using XML serialization. To do the serialization, I understand that all the variables must be public and that I need to create a parameterless constructor. Some of the reading that I've done recommend that the I should keep these global variables private and use properties to access and update the values.

Any suggestions on how I can allow serialization while at the same time comply with some common practices/standards? Do I have seperate copies of the Person class the lite version and the full version. Think I'd run into problems when I went to deserialize the XML in that scenario.

Regards

Michael.

4 Replies

Know the answer? Post it — somebody with the same question will find it here.

Sam Hobbs15y ago
I also have an article about the XmlSerializer class; see XmlSerializer class for reading and writing XML. I did not mention it previously since I assumed you (Michael) only needed a nudge. There are many other articles about XML serialization in this web site.
Zoran Horvat15y ago
Michael, I've written an article on this topic. It might be interesting to you: Best Practices in .NET XML Serialization of Complex Classes
Sam Hobbs15y ago
Why do you say "all the variables must be public"? What are you using that that applies to? Using the XmlSerializer class, you can have public properties and private "variables".
Zoran Horvat15y ago
First, you don't have to make fields (member variables) public - rather properties used to get/set those fields should be public. You can use XmlAttributeAttribute and XmlElementAttribute attributes to specify how these properties should be written to XML (either as attribute of the element which represents Person, or as a child element).

This way is good for simple objects as Person is. However, suppose that you add a properties Mother and Father, which are again of type Person. You should not serialize those properties (i.e. you should use XmlIgnoreAttribute on it). That is because otherwise child XML elements would be created and Mother and Father objects would be serialized in them. Further on, their own Mother and Father properties would be serialized under each of them, and so on. The problem with this is: suppose there are objects joe and mary of type Person. They both reference same objects wilma and pete as Mother and Father. Now create an array of those four persons and serialize it into XML. That would create three copies of wilma and pete! Now deserialize it, and it will create different Person objects that represent wilma and pete. Now suppose you have a method called IsBrotherOrSister, which would return true on joe and mary before serialization. Well, after deserialization it would return false for both of them.

I hope that I've given you something to think about. Generally speaking, built-in XML serialization is good in sense that it allows you to hand off a lot of work. On the other hand you must think about serialization in advance - not every object can be serialized/deserialized without damage, as shown above. So you must design objects knowing that they will be subdued to XML serialization. Even more, some classes cannot be designed so that serialization can be performed without serious cuts in design, which can be undesirable. In such cases, I prefer creating simplified serialization-friendly class of which objects are created from complex class objects when serialization is required. In general, whenever I have a more complex object model, I prefer creating these serialization-friendly classes rather than forcing regular classes to be serializable, because that may lead to serious design problems.