Is this Better than Constructor Injection?

Date August 29, 2008

So after I finished my post on property injection I thought of something, maybe I shouldn’t use constructor injection for my classes.  Maybe, I can just use lazy properties that would call my IoC (Ninject) Kernel to instantiate the object.  So instead of defining a constructor like this:

public IAccountService Service { get; set; }

[Inject]
public AccountController(IAccountService service)
{
    Service = service;
}

I could just have a property Service do the work like this:

public IAccountService Service
{
    get
    {
        return (IAccountService) Kernel.Get(typeof (IAccountService));
    }
}

If I get rid of all my constructor parameters then I won’t need to change my ControllerFactory to use the Ninject Factory.  This keeps looking better and better.

What do you think?  I keep reading everywhere that construction injection is the way to go.  But why complicate my constructor when I can have the properties do the heavy lifting?  I would love to hear what you think.

Related Posts

kick it on DotNetKicks.com

Category Posted in MVC Book, asp.net mvc
Category Tags: , , , ,

Viewing 6 Comments

    • ^
    • v
    The benefit that ctor injection brings is more about predictability than discoverability.

    It isn't so obvious when you're in 'author' mode, because at that point you're intimately familiar with the class's internals and don't find any of its interactions with the rest of the system 'surprising'.

    As a user or maintainer of a class, however, you need to be aware of both the provided interfaces, and the required interfaces *equally*. Otherwise, you can have a very hard time when trying to determine exactly how methods called on that class will affect the rest of the application.

    Provided interfaces -> interface implementations
    Required interfaces -> constructor parameters

    The second isn't necessarily any less important than the first.

    (Properties can't be used to emulate the same role, as it is impossible to determine from a property declaration whether the property represents a required interface or just exposes functionality provided by an aggregated component.)

    Hope this helps!

    Nick
    • ^
    • v
    Ok that makes perfect sense and was sort of what I was thinking but you expressed it much better.

    I guess if you are writing a framework or code that will be used by others then it makes sens to go with constructor injection because it is explicit what interfaces are the class dependent.

    If I used a property that automatically creates the interface from IoC container i.e. Kernel.Get...., it will work just the same but then the consumer of that class doesn't know that. He doesn't know which interfaces need to be configured in his IoC container configureation and so on...

    What if we can configure a class like this:

    [Inject(IService1, IService2, IService3)]
    class MyClass

    This way, I don't have to "pollute" my constructor and it is still somewhat discoverable and predictable. What do you think?
    • ^
    • v
    Starting to get well into 'service locator' territory here - there's a lot of discussion out there about the relative merits of each.
    • ^
    • v
    I'm not sold on constructor injection either. It seems like the biggest argument for it is discoverability, but I just kind of feel like it dirties up my classes for some reason. For the same reason, I've been enjoying Autofac's support for property injection without having to use any [Inject]-style attributes.
    • ^
    • v
    I don't like your property implementation at all. You now have an explicit dependency on the IoC container. Remember IoC is 90% about the IoC/DI pattern and only 10% about the mechanics of how your IoC container works. I've got applications that leverage an IoC container but the only place where the IoC container is referenced is on application startup. I think constructor injection makes perfect sense, rather that polluting a service implementation it's making explicit its dependencies.
    • ^
    • v
    Mike,
    You wrote, "I've got applications that leverage an IoC container but the only place where the IoC container is referenced is on application startup.".
    Can you explain how you accomplish this?
    Thanks!
    Lee

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus