Is this Better than Constructor Injection?

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.

This entry was posted on Friday, August 29th, 2008 at 6:02 pm and is filed under ASP.NET MVC. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

http://www.squaredroot.com TroyGoode

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.
http://ubik.com.au Nicholas Blumhardt

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
eibrahim

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?
http://aspdotnetmvc.com/blogs/default.aspx ASP.NET MVC Archived Blog Posts, Page 1

[...] to VoteIs this Better than Constructor Injection? (8/29/2008)Friday, August 29, 2008 from http://www.emadibrahim.comSo after I finished my post on property injection I [...]
http://mikehadlow.blogspot.com/ Mike Hadlow

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.
Lee Byrd

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
http://ubik.com.au Nicholas Blumhardt

Starting to get well into 'service locator' territory here – there's a lot of discussion out there about the relative merits of each.
Chr4is

I'm with Mike.

For example:

In a simple MVC app. I have my CustomControllerFactory locate my controllers. My controllers have constructor dependencies on some Services. My Services have dependencies on infrastructure objects (repository, etc…).

The only place my app has a dependency on the container is in the CustomControllerFactory. The container is totally transparent.

Start throwing your service locator everywhere, you're bound to have a problem.
Chr4is

I'm with Mike.

For example:

In a simple MVC app. I have my CustomControllerFactory locate my controllers. My controllers have constructor dependencies on some Services. My Services have dependencies on infrastructure objects (repository, etc…).

The only place my app has a dependency on the container is in the CustomControllerFactory. The container is totally transparent.

Start throwing your service locator everywhere, you're bound to have a problem.

Emad Ibrahim