NInject and MVC 3 - Should I use DependencyResolver instead of [Inject] attribute?

Question

Recently I moved to MVC 3 and Ninject 2. In most of the code, I use constructor injection, but there are some places, where I had to use Inject attribute. Ninject 2 registers its own IDepencyResolver interface. I don't like DependencyResolver class being part of System.Web.Mvc namespace, because its function is not really strictly related to MVC, but now, when it is there, I can do

public SomeClass 
{
    public IUserService UserService { get; set; }

    public SomeClass()
    {
        UserService = DependencyResolver.Current.GetService<IUserService>();

instead of

public SomeClass 
{
    [Inject]
    public IUserService UserService { get; set; }

so I don't have to reference Ninject namespace in my classes. Should DependencyResolver be used like that?

score 5 · Accepted Answer · answered Feb 16 '11 at 17:59

I use property injection only for dependencies that are not required for the proper working of the class but could add some functionality if the user sets them. Example of such functionality is logging. So you could have a property which represents a logger where the user can supply his own implementation and if he doesn't the class continues to work normally but it simply doesn't log.

For everything else I use constructor injection. This way you indicate to the consumer that this class has a required dependency on some other service.

So to answer your question about the property injection I would simply have:

public SomeClass 
{
    public IUserService UserService { get; set; }

    public void SomeMethodWhichDoesntEnforceUserService()
    {
        if (UserService != null)
        {
            // Provide some additional functionality
        }
    }
}

and if your class cannot function properly without the user service:

public SomeClass 
{
    private readonly IUserService _userService;
    public SomeClass(IUserService userService)
    {
        _userService = userService;
    }

    public void SomeMethodWhichRequiresTheService()
    {
        _userService.DoSomething();
    }
}

So in both cases no reference to any DI specifics. That's what Inversion of Control is all about.

And what do you do when BaseClass has for example 3 interfaces injected in constructor and InheritedClass has additional 2. Do you make constructor with 5 parameters? — LukLed, Feb 16 '11 at 18:03
@LukLed, yes, but in general I try to reduce the number of dependencies. 5 seems pretty large. It means that your class is doing too much things and you should probably consider splitting it into different classes. — Darin Dimitrov, Feb 16 '11 at 18:05
Too much? `IPrincipal` is injected, `IRepository` is injected, `IApplicationCache` is injected in BaseClass. These are basic items, used in all services. I just try to inject as much, as I can, instead of referencing directly. That makes a lot of parameters in constructor. Ok, I can handle it with aggregate services. — LukLed, Feb 16 '11 at 18:13

score 1 · Answer 2 · edited May 23 '17 at 11:47

1

First question I would ask is why you can not perform constructor injection of the IUserService into SomeClass? It may indicate an issue with the design.

To avoid direct reference to the DependencyResolver you could implement some form of abstraction of a Service Locator over the DI framework, e.g. CommonServiceLocator, but as the answer to this question indicates, such abstractions shouldn't be necessary when doing DI correctly. Instead you should adjust the design of the application.

edited May 23 '17 at 11:47

Community

1
1

answered Feb 16 '11 at 17:48

Pero P.

25,813
9
61
85

`DependencyResolver` is some kind of abstraction over `DI` library. This class is not related to Ninject. I am using `Inject` attribute in base classes, because I don't want to add parameters to constructor of every inheriting class. I also had some circular reference issues. – LukLed Feb 16 '11 at 17:56
Ah apologies, I'm not too familiar with ninject but automatic constructor injection isn't an option if you're concerned with polluting code with ninject references? http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/ – Pero P. Feb 16 '11 at 18:06
Constructor injection is an option, but I don't want to have huge constructors. Ok. I probably do too much thinking, when there is not much to think about. – LukLed Feb 16 '11 at 18:34

score 0 · Answer 3 · answered Feb 16 '11 at 18:01

0

I believe the ninject.web.mvc version for mvc3 now supports constructor injection on filter attributes. Have you tried it?

answered Feb 16 '11 at 18:01

dotjoe

26,242
5
63
77

Is it even possible? If you don't specify all required constructor parameters, code won't even compile. – LukLed Feb 16 '11 at 18:27
@LukLed I haven't had the time to try it but it looks like it's possible...https://github.com/ninject/ninject.web.mvc/tree/master/mvc3/src/SampleApplication/Controllers/FilterInjectionExamples seems like he's using a normal attribute as a marker to inject the filterattribute. – dotjoe Feb 16 '11 at 22:48

NInject and MVC 3 - Should I use DependencyResolver instead of [Inject] attribute?

3 Answers3