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

Its been more than a year since I asked this question, and I know more now than I did back then. Kevin's answer is correct and best practice, but sometimes you need to work with legacy classes and want to do something like I have in my question. Here's how I do it with NInject:

public class Person
{
    [Inject]
    public IPersonRepository PersonRepository { get; set; }

    private string _name;

    public Person(string name)
    {
         _name = name;
         StaticKernelContainer.Inject(this);
    }
}

An implementation of StaticKernelContainer can be found in the NInject Web extensions project.

Answer 2

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.