Let's say I have a LoginView and its data context, LoginViewModel, needs to be injected with a service that can authenticate a user based on their username/password.
Now let's say that the state of the application is that someone has already logged in, but now they are logging out and I need to redisplay the login screen for the next user. So at this point I need an instance of my LoginViewModel but I'm not sure how to go about getting it.
Should I be injecting a LoginViewModel into my ShellViewModel and holding onto it and reusing it? That seems odd because why would I want to keep that in memory while I'm not using it (granted, not a big deal in this case but could be for other cases).
Should I be injecting the authentication service into ShellViewModel to hold onto for whenever it needs to create a LoginViewModel? That seems odd because my ShellViewModel doesn't need to do anything with this service and if this were the answer then I'd be injecting all kinds of stuff into my ShellViewModel for all the other ViewModels it displays.
And I know I'm not supposed to be referencing my DI container anywhere other than the root of my application or I'll be implementing a Service Locator pattern.
Admittedly, I'm feeling pretty dumb right now and I'm sure I'm going to slap myself in the face when I hear the answer... so what is it?
After having done nothing but look up various blogs, questions, and answers on this subject for the past several hours I'm beginning to come to a conclusion that a framework such as Asp.net MVC makes implementing a purist's (aka someone like Mark Seemann) approach quite doable.
Such frameworks tend to make this possible because the framework itself utilizes a (gasp!!!) Service Locator pattern. Unfortunately, using an MVVM design on a platform like WPF doesn't make it quite as easy due to the nature of how your views aren't always served up from the root with the help of a built in Service Locator.
I do, however, have a ShellViewModel that is responsible for showing most the views I need and so I think the most practical answer here is for me to consider my ShellViewModel as part of the composition root and extend my dependency on the DI container into it.
Beyond the point of my ShellViewModel though, I believe 500's answer is correct.
In a scenario like this I usually inject what would correspond to a LoginViewModel factory in your case. That way your logic can manufacture a new (or possibly cached by the factory) instance as needed.