views:

137

answers:

1

This is what I want from DI container:

public class Class
{
   public Class(IDependency dependency, string data)  { }
}

var obj = di.Resolve<Class>(() => new Class(null, "test"));

Points of interest:

  1. Can resolve both dependency and data in constructor.
  2. Can use type-safe syntax to pass constructor parameters (exact syntax may vary). Yes I can do it myself by getting constructor arguments from (Expression.Body as NewExpression) - but I'll need a way to detect what arguments are registered in the container.

Another major requirements is that I'd like my components to be automatically picked up, i.e. I don't want to register Class - I want IoC to pick it up because it knows how to resolve IDependency.

Also, Property Injection can be useful sometimes, but this is optional.

The question is really about the combination of features - to have all of them - type-safe, parameters, automatic pick-up... It's easy to check one feature, but a combination of them is not easy to verify unless one's familiar with particular container and knows its features. Thus the question.

+3  A: 

I think you would be better off by defining an Abstract Factory that can create your class.

public interface IFactory
{
    MyClass Create(string data);
}

You could then create an implementation of IFactory like this:

public class MyFactory : IFactory
{
    private IDependency dependency;

    public MyFactory(IDependency dependency)
    {
        if (dependency == null)
        {
            throw new ArgumentNullException("dependency");
        }

        this.dependency = dependency;
    }

    #region IFactory Members

    public MyClass Create(string data)
    {
        return new MyClass(this.dependency, data);
    }

    #endregion
}

In your container, you would register both MyFactory and the implementation of IDependency.

You can now use the container to resolve the Factory, and the Factory to get the class:

var mc = container.Resolve<IFactory>().Create(data);

This approach is completely type-safe and nicely decouples the dependencies from run-time application data.

Mark Seemann
Exactly!......................
Martinho Fernandes
Bonus points for calling it by the name Abstract Factory, but using an interface. I've seen a lot of people that when they hear *Abstract* Factory go straight to abstract base class.
Martinho Fernandes
Yes I know this, though in my case I hesitate because for simple cases it's overkill to duplicate constructor with interface, factory, factory's constructor, Create method, etc. While good for complex cases, it's too "DI explosion" for simple things I think. And the question remains about automatic registration DI container.
queen3
@queen3: I understand what you mean, but I'm not aware of any DI Containers that can do what you ask. Incidentally, AutoFixture (http://autofixture.codeplex.com/) has a syntax that is very close to the one you ask about, but it's not a DI Container :/ I did see your other question about auto-registration, but don't (yet) have a good answer.
Mark Seemann
I currently think about implementing both type-safe creation and auto-registration myself, for this I need to know "if type can be instantiated by container" from the type - I think http://stackoverflow.com/questions/1550190/list-all-types-registered-with-a-castle-windsor-container-instance will do but I'm not sure. Of course a container that does this already would be much better than a half-baked custom solution...
queen3