Question

I am looking for suggestions as to the best way to design objects for IoC

Suppose I have an object (Service) that has a dependency to a DataContext which is registered with Ioc.

But it also requires a name property, i could design the object like this:

class Service
{
    public Service(IDataContext dataContext, 
        string name)
    {
        this._dataContext = dataContext;
        this._name = name
    }

    public string Name
    {
        get
        {
            return _name;
        }
    }
}

The problem is it becomes very complicated to use with Ioc containers as a string object such as name is not easy to register and the usage becomes complicated with the Ioc container:
So resolution becomes confusing:

var service = Ioc.Resolve<Service>( ?? )

Another approach is to design it as follows:

class Service
{
   public Service(IDataContext dataContext)
   {
        this._dataContext = dataContext;
   }

    public string Name { get; set; }
} 

The resolution is now easier:

var service = Ioc.Resolve<Service>();
service.Name = "Some name";

The only downsite is specifying the name is no longer required.
I would like to hear from DI or IoC experts how they would go about designing this and still stay fairly agnostic to the concrete Ioc container technology.

I know that a lot depends on how you want to use this, option 2 would be perfect if name really was optional. But in the case where name is required you could add the validation step at another point in code, but rather go for the design to make Ioc simpler.

Thoughts?

Answer 1

Your choice of DI Container shouldn’t dictate the design of your API. If name isn’t optional, it should be part of the constructor’s signature (thus making it mandatory).

The next question then becomes how to configure the container without incurring tons of overhead. How to do that depends on the container. Here’s how to implement a convention around a string argument in Castle Windsor:

public class NameConvention : ISubDependencyResolver
{
    public bool CanResolve(CreationContext context,
        ISubDependencyResolver contextHandlerResolver,
        ComponentModel model, DependencyModel dependency)
    {
        return dependency.TargetType == typeof(string)
            && dependency.DependencyKey == "name";
    }

    public object Resolve(CreationContext context,
        ISubDependencyResolver contextHandlerResolver,
        ComponentModel model, DependencyModel dependency)
    {
        return "foo"; // use whatever value you'd like,
                      // or derive it from the provided models
    }
}

Then register the NameConvention with the container like this:

container.Kernel.Resolver.AddSubResolver(new NameConvention());

If your container doesn’t have the appropriate extensibility points, pick a container that does.