In fact, both of these solutions are bad.
Creating a services singleton (IServices) containing all the available services as interfaces. Example: Services.Current.XXXService.Retrieve(), Services.Current.YYYService.Retrieve(). That way, I don't have a huge constructor with a ton of services parameters in them.
This is essentially the Service Locator Pattern, which is an anti-pattern. If you do this, you will no longer be able to understand what the view model actually depends on without looking at its private implementation, which will make it very difficult to test or refactor.
Creating a facade for the services used by the viewModel and passing this object in the ctor of my viewmodel. But then, I'll have to create a facade for each of my complexe viewmodels, and it might be a bit much...
This isn't so much an anti-pattern but it is a code smell. Essentially you're creating a parameter object, but the point of the PO refactoring pattern is to deal with parameter sets that are used frequently and in a lot of different places, whereas this parameter would only ever be used once. As you mention, it would create a lot of code bloat for no real benefit, and wouldn't play nice with a lot of IoC containers.
In fact, both of the above strategies are overlooking the overall issue, which is that coupling is too high between view models and services. Simply hiding these dependencies in a service locator or parameter object does not actually change how many other objects the view model depends on.
Think of how you would unit-test one of these view models. How big is your setup code going to be? How many things need to be initialized in order for it to work?
A lot of people starting out with MVVM try to create view models for an entire screen, which is fundamentally the wrong approach. MVVM is all about composition, and a screen with many functions should be composed of several different view models, each of which depends on only one or a few internal models/services. If they need to communicate with each other, you do so via pub/sub (message broker, event bus, etc.)
What you actually need to do is refactor your view models so that they have fewer dependencies. Then, if you need to have an aggregate "screen", you create another view model to aggregate the smaller view models. This aggregate view model doesn't have to do very much by itself, so it in turn is also fairly easy to understand and test.
If you've done this properly, it should be obvious just from looking at the code, because you'll have short, succinct, specific, and testable view models.
Seems fine to me. ViewModel defines an interface it requires View to implement. But you should only use this when you can't use data binding properly. Eg. you want view to do some action that is not tied to data the view presents.
Why I think this is fine is: The major point of MVVM (or MVP for that matter) is to remove direct dependency between View and ViewModel in either direction. In MVVM, this is mostly achieved by heavy use of reflection in data binding. But sometimes that is not enough, because you cannot easily invoke some action on View from ViewModel. To do that, you create abstraction that represents this action so ViewModel can call this abstracion and View realizes this abstraction. This way, there is still no direct dependence between View and ViewModel, but you can overcome the limitation of data binding.
Best Answer
Personally I would not have an issue with the view model constructor taking an
LDLTrack
and using it to populate itself. That's a fairly tidy, well-encapsulated way of doing things.What I wouldn't be so keen on is then exposing that model to consumers via a property - instead, I'd populate fields explicitly defined for the properties that the view model represents:
This will help to reduce coupling - the view model's job is to communicate certain information and the constructor allows the
LDLTrack
model to be one source of that information, without further binding other consumers to that type.