Constructor injection with other, non-dependency, constructor arguments

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.

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.

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.

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