Questions regarding appropriate use of ViewModelLocator in MVVM

Question

I am working on a WPF/MVVM app using MVVM Light. Right now my ViewModelLocator is pretty standard; it includes a static constructor that registers the ViewModels via SimpleIoc and has properties returning the current instances of the ViewModels.

I don't know how appropriate this is, but I have been exploring using instances of ViewModelLocator in ViewModels to access properties of other ViewModels and to change ContentControl in one of my views. If there are any major problems with doing that, please let me know so that I can find a way around it. For example, I may have something in a ViewModel like:

private ViewModelLocator _viewModelLocator = new ViewModelLocator();

private void SomeMethod()
{
    _viewModelLocator.OtherViewModel.SomeProperty = something;
}

In a different ViewModel I have the following:

private ViewModelLocator _viewModelLocator = new ViewModelLocator();

public ViewModelBase CurrentViewModel { get; set; }

private void SomeMethod()
{
    CurrentViewModel = _viewModelLocator.SomeViewModel;
}

In this case, CurrentViewModel is bound to a ContentControl in my view.

At the moment being able to do this is very convenient but I'd like to get some input from more experienced programmers to make sure that I'm not shooting myself in the foot. If there is a problem with it, are there more acceptable routes I can take to achieve the same results?

---

Now, if there is nothing wrong with the aforementioned approach, I would like to know if it would be appropriate and/or acceptable to make ViewModelLocator static. To try things out, I did a quick changeover to a static ViewModelLocator. In my MainWindow.xaml, I set the DataContext to:

DataContext="{Binding Source={x:Static vm:ViewModelLocator.Main}}"

...and going back to the first example, I can use:

private void SomeMethod()
{
    ViewModelLocator.OtherViewModel.SomeProperty = something;
}

and:

public ViewModelBase CurrentViewModel { get; set; }

private void SomeMethod()
{
    CurrentViewModel = ViewModelLocator.SomeViewModel;
}

Right now the program works fine using a static ViewModelLocator, but it is in its infancy, so I'd like to know if this is something that could be a viable option in the future or if I should stay away from a static ViewModelLocator altogether.

Any advice or input on these issues would be greatly appreciated. I am still fairly new to programming and I would like to learn techniques that will serve me well in the long run.

If there are no glaring issues with what I'm doing here, please let me know as well.

Thanks.

Answer 1

It is considered incorrect to reference other view models from view models. This breaks the decoupling that is supposed to make you project more testable and maintainable. If I need to have properties accessable from a number of view models I create a service like iUniversalAppDataService and then use the dependency injection built into MVVM-Light to resolve when the vewimodel is created.

ie this is the constructor of your viewmodel:

public New(IUniversalAppDataService AppDataService)
{
    _MyAppDataService = AppDataService;
}

That way any changes/properties within that service are available to any viewmodel that implements the service.

the service needs to be declared in the viewmodellocator as well:

SimpleIoc.Default.Register<IUniversalAppDataService , UniversalAppDataService >

I have used this method to create navigation services that respond to user navigation and of course data services from databases or web data services. I strongly suggest using this service approach because it is WAY easier to maintain in the long run should there be changes to your underlying data model or app architecture.