Question

In my current project, I have quite a few objects I need to persist to XML and inflate at runtime. I’ve been managing this through .NET’s DataContracts. What I am doing right now is creating a separate class that represents the objects I’m serializing and reading/writing those to/from disc to avoid having too much responsibility in a single class. Here’s an example:

public class Range
{
    private float _min;
    private float _max;

    public float Min { get { return this._min; } }
    public float Max { get { return this._max; } }

    // Constructrs & Methods...

    public SerializedRange GetAsSerializable();
}

The Range class has the complimentary class:

[DataContract]
public class SerializedRange
{
    [DataMember]
    public float Min;

    [DataMember]
    public float Max;

    // Constructor...
}

My question then is, who should be responsible for actually taking the Serialized version of the object and inflating it into the actual object? I see three options, but I’m not sure which (if any of them) would be the best:

1. Give the Serialized version of the object an instance method that spits out an inflated instance, using the available constructors/factories of the sister class.
2. Give the sister class a factory that takes an instance of the serialized version to construct itself.
3. Don’t have either the class or it’s Serializable counterpart do anything- have the code that reads in the Serialized objects manually create the regular objects using whatever constructors/factories they’d regularly have.

I realize that in certain situations you’d have to do it one way or the other because of constraints outside of this somewhat contrived example. Since there’s more then one way to do it though, what I’m really looking for is a general rule of thumb that yields neat, readable, and expandable code.

Answer 1

If you ‘break’ you application into constituent parts what logical components would you get? Here are few based on my understanding:

1. Domain Objects (Data that you are storing)
2. Data Layer – responsible for persisting the data (and retrieving it)

and many others (but just taken a subset as per your description)

Now, the job of the data layer is to write the content out to some storage – XML files to disk in your case.

Now, when you ‘query’ the file who fetches it? The data layer. Who ‘should’ populate the corresponding domain object? Well the data layer itself.

Should the data layer ‘delegate’ the responsibility of population to a separate class/factory? It depends if it’s ever going to be reused by someone else. If not, concepts like inner classes can be of good help (they exist in the java world, not sure of it’s equivalent in C#.NET). That way you’ll have it modularized into a specific class, which is not publicly visible to other classes, unless you want it that way.

Should you go with factory? Yes, you may. But make sure it’s logically correct to do so. You could land up with many object inflators – that could isolate the inflation functionality to one class and the factory could itself be a part of the data layer (if you want it that way).

Once you delineate the concerns you’ll be in a better position to decided where to put that piece of code. I’ve provided some pointers that could come in handy.

Hope it helps…