Constructor injection with other, non-dependency, constructor arguments

Question

I'm new to IOC containers, and I'm getting started with NInject.

What do you if you want your constructor to have parameters that are not services and don't need to be instantiated by the IOC container?

For example:

public class Person
{
    private readonly string _name;
    private readonly IPersonRepository _repository;

    public Person(string name, IPersonRepository repository)
    {
        _name = name;
        _repository = repository;
    }

    ......
}

Imagine that name is a requirement of the Person class, so, to ensure that a Person always has a name, we require that it be passed in to the constructor.

How would we get an instance of Person using NInject? The name needs to be passed in by whichever bit of the app is creating a new Person, whilst the IOC container needs to pass in the IPersonRepository.

I understand that either the name or the repository could be injected using a property instead, but this would not be a clean solution - we are losing some of the programming language's semantic power.

Answer 1

The class, as written above, wouldn't be a good candidate for use with an IOC container. You are mixing concerns here with the Person entity holding some state (the name) and performing some action (whatever the repository is used for). If you refactor your code so that the Person entity is retrieved or created via a class that takes an implementation of the IPersonRepository via the constructor then you'll be in a spot where the dependency injection makes better sense.

Answer 2

I respectfully disagree with Kevin McMahon's response above, and the reason is that I have seen dependency injection code that does exactly what you want ... only with a different IoC container. Namely, it was Castle Windsor, which is another Ioc container. It would allow you to create a section in your config file to say what values to provide for name (doesn't make much sense to do that for name, but if it was a property like "connectionString", it might make a lot of sense).

So ... it's not that what you are trying to do is not a fit for dependency injection in general ... it's just that Ninject doesn't seem comfortable with it (or perhaps Ninject can accommodate it as well ... I don't know all of its lesser used features well enough to say).