93

Closed

Add support for IoC containers

description

Using ContactManager sample as an example - there should be a way to have a container build the ContactsResource, injecting IContactRepository instead of having it explicitly instantiated in default constructor as it is now. The framework should then resolve ContactsResource against the container. I imagine that instead of using concrete ContactsResource implementation this could be also done for interfaces (assuming we would register and interface in Global.asax.cs : RouteTable.Routes.AddServiceRoute<IContactsResource>("contacts", configuration);).
[ServiceContract]
public class ContactsResource
{
    private readonly IContactRepository repository;

    public ContactsResource(IContactRepository repository)
    {
        this.repository = repository;
    }

    public ContactsResource()
        : this(new ContactRepository())
    {
    }

    [...]
Closed Sep 12, 2011 at 11:30 PM by danroth27
You can now wire up an IoC container using the CreateInstance property on HttpConfiguration.

comments

cwoodruff wrote Nov 1, 2010 at 11:23 AM

Yes. I see it as handy in mocking and refactoring services in projects.

ploeh wrote Nov 1, 2010 at 11:28 AM

Let's rephrase this requirement: it shouldn't be about container support - it should be about support for Constructor Injection. In other words, it should be possible to define ContactsResource without a default constructor. A DI Container can be used to compose ContactsResource, but that's actually of less importance...

mauricedb wrote Nov 1, 2010 at 11:33 AM

This can already be done using the IInstanceProvider interface. That said, it is way to hard to discover and do so I am all for a standard inplementtaion using the common service locator.

bjorncoltof wrote Nov 1, 2010 at 11:35 AM

I don't agree with earlier remark about the constructor injection, I would like the ContactsResource to be resolved using a container, constructor injection is just one of the options in that case.

ploeh wrote Nov 1, 2010 at 12:16 PM

@bjorncoltof No, it's the other way around. Given that you have Constructor Injection, you can choose to resolve it with a DI Container, or you can do it with Poor Man's DI. A DI Container in itself is not going to magically enable you to get rid of the default constructor, and neither is the Common Service Locator.

bjorncoltof wrote Nov 1, 2010 at 3:05 PM

@ploeh I was actually trying to widen the scope a bit, what if I don't want to use constructor injection, but use setter instead (for whatever reason)? I would love to leave the how-to-construct part up to a container and just tell it give me the IContactsResource implementation. And I guess the added wish is to get rid of the default constructor...

ploeh wrote Nov 1, 2010 at 6:30 PM

@bjorncoltof Okay, I slightly misunderstood you then. I have no problem with Property Injection also being possible (although I find that pattern only marginally useful) as long as Constructor Injection is. However, whether or not it's a DI Container or some other Composer that composes ContactsResource is, IMO, of much less importance. What I'm really trying to say is that composition should be supported without relying on Common Service Locator or any specific DI Container.

bjorncoltof wrote Nov 1, 2010 at 9:01 PM

@ploeh Completely agree!

RobertWilczynski wrote Nov 1, 2010 at 9:29 PM

@bjorncoltof, @ploeh maybe "support for IoC containers" is a bit too broad - my intention when adding the work item was primarily constructor injection but I guess at this point it's hard to implement constructor injection only and leave property injection out - that just comes by default with most (all?) containers. I wonder if we really have to be explicit about the fact that we don't want service locator anywhere near us in this scenario - this should be obvious by now.

DarrelMiller wrote Nov 2, 2010 at 2:39 AM

sedanwer wrote Nov 2, 2010 at 5:50 AM

A generic IoC or....? As for us we are already using StructureMap for this as well as for the rest of our dependent objects. Wouldn't like to be forced having two. //Daniel

ploeh wrote Nov 2, 2010 at 8:01 AM

@RobertWilczynski Sounds good. I just wanted to add my 2c to prevent this feature going in the same horrible direction as ASP.NET MVC 3 currently is headed :)

RobertWilczynski wrote Nov 2, 2010 at 2:32 PM

@ploeh point taken - I guess one can never be too explicit :)

gblock wrote Nov 4, 2010 at 8:04 AM

We're currently prototyping a new code-based config model. Take what we have in the current drop (HostConfiguration) much further to where you could configure everything you do today in web.config / attributes via code. Once we do that I think we'll have a nice place to fit in plugging your IoC. I "may" prototype this for the next drop.

gblock wrote Nov 4, 2010 at 8:06 AM

@sedanwer The design we would shoot for would not be opinionated and force you to use a particular IoC.

gblock wrote Nov 4, 2010 at 8:07 AM

@RoberyWilczynski it is not hard to support constructor injection. Our IIinstanceProvider extension point (which we would likely use) totally supprots this as it is a factory.

gblock wrote Nov 4, 2010 at 8:08 AM

@ploeh agreed that you don't HAVE to use an IoC container. The main point is having a factory hook for creating services. The implementation of the factory might support constructor injection _or_not, but that is besides the point.

gblock wrote Dec 3, 2010 at 7:17 PM

Just as a follow up to this, I put together a prototype that illustrates an approach for supporting IoC throught the configuration calss. You can read about it here: http://codebetter.com/blogs/glenn.block/archive/2010/11/15/exploring-resources-a-resource-programming-model-and-code-based-configuration.aspx

gblock wrote Dec 14, 2010 at 12:32 AM

Hey Mark, stop turning this into another place to promote your book ideas :-)