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.

Advertisements

0 thoughts on “Is this Better than Constructor Injection?

  1. 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.

    Like

  2. 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 implementationsRequired interfaces -> constructor parametersThe 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

    Like

    • 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 MyClassThis way, I don't have to “pollute” my constructor and it is still somewhat discoverable and predictable. What do you think?

      Like

  3. Pingback: ASP.NET MVC Archived Blog Posts, Page 1

  4. 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.

    Like

  5. 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

    Like

  6. 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.

    Like

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

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s