Question

I’m working on a project that uses dependency injection via Ninject. So far, it is working out very well, and I’m liking DI a lot, but now I have decided I need to serialize some objects, and I’m finding it difficult to do that following DI patterns.

Say I have a class called Foo, which has a list of Bars, and makes them through a factory, like this:

public class Foo
{
    private List<Bar> _bars;
    private BarFactory _barFactory;

    ...

    public void MakeBar()
    {
         _bars.Add(_barFactory.MakeBar());
    }
}

Here’s Bar, which gets made when _barFactory.MakeBar() gets called. I want Bar to be serializable:

public class Bar : ISerializable
{
    private List<IPickle> _pickles;
    private PickleFactory _pickleFactory;

    public Bar(PickleFactory factory)
    {
         _pickleFactory = factory;
    }

    public void MakePickle(int x)
    {
         _pickles.Add(_pickleFactory.MakePickle(x));
    }

    public void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        //serialize member variables here
    }

    //Constructor called during deserialization
    private Bar(SerializationInfo info, StreamingContext context)
    {
        //fill in member variables with data from SerializationInfo
    }
}

Notice that Bar has its own factory and a collection of pickles. Here’s the problem: when the deserialization constructor of Bar gets called, I don’t have any way to get it another PickleFactory. The original PickleFactory was given to Bar by the BarFactory, but the deserialization constructor wasn’t called by BarFactory.

My current plan to solve this problem would be to extract all the serializable members of Bar into its own class called BarDataObject. Then I would make the BarDataObject serializable, but not Bar itself. I would add a function to BarFactory which accepts a BarDataObject as a parameter and builds a Bar for you filled in with all the information from the BarDataObject.

However, suppose Pickle also has service classes which it got from the factory that made it, which can’t be serialized either. So I would have to extract a DataObject from Pickle as well, and my BarDataObject would have to hold onto a PickleDataObject. And suppose Pickle had a member variable with a mix of data and services too? I would have to make and maintain a DataObject for that as well. This seems like a real bummer, especially considering my project has many other things which I need to serialize, and they’ll probably face the same problem.

So is there a better solution? Am I doing something wrong, DI-wise? I’ve just started working with DI and Ninject, but I can’t seem to find anyone who’s come up with a good way to serialize objects which got injected with service classes.

Answer 1

In my experience, only service classes should have dependencies, and service classes should never be subject to serialization.

The fact that you have a class that you want to serialize, but which relies on an injected service, seems like a code smell to me.

It’s difficult to tell exactly what you’re trying to accomplish with Bar, but from what I can see, I’d suggest making Pickle be a POCO, and using a List<Pickle> instead of a custom Bar class.

Or, if Bar is intended to have other serializable information besides the Pickles, make Bar a POCO with a Pickles property:

public class Bar
{
    public string Name {get;set;}
    public List<Pickle> Pickles {get;set;}
}

Because POCOs won’t have dependencies, they shouldn’t require factories, so this class should be entirely serializable. If there are complex functions that you’d like to perform on Bars and Pickles, they should be abstracted out into separate utility services that take Bars and Pickles as their method parameters.