First, lets look at what ViewModelLocator does and why we use it:
ViewModelLocator is declared as an object on our App.xaml page and is an application singleton. We're going to have one, and only one of them available to the application when it runs.
ViewModelLocator is the source for all our ViewModels in MVVM Light. For each ViewModel we'll have a property on the ViewModelLocator that allows us to get a ViewModel for a View. This code looks like this:
public class ViewModelLocator
{
public MainPageViewModel MainPage
{
get { return new MainPageViewModel(); }
}
}
This is a piece of my App.xaml:
<Application.Resources>
<vm:ViewModelLocator
x:Key="ViewModelLocator" />
</Application.Resources>
This is a piece from View.xaml
DataContext="{Binding MainPage, Source={StaticResource ViewModelLocator}}"
So far so good. To answer your first question, do you have to use Ioc in MVVM Light? No. There's no need as your viewmodel will be given to your view fully built and instantiated by the ViewModelLocator.
Now, onto your second question: What's the purpose of IoC?
IoC is designed to allow you to do the following:
With Mvvm Light you do the above like this:
public class ViewModelLocator
{
public ViewModelLocator()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
if (ViewModelBase.IsInDesignModeStatic)
{
SimpleIoc.Default.Register<IDataService, Design.DesignDataService>();
}
else
{
SimpleIoc.Default.Register<IDataService, DataService>();
}
SimpleIoc.Default.Register<MainViewModel>();
}
public MainViewModel Main
{
get { return SimpleIoc.Default.GetInstance<MainViewModel>(); }
}
}
public class MainViewModel
{
public ObservableCollection<Foo> Foos { get; set; }
public MainViewModel(IDataService dataService)
{
_dataService=dataService;
Foos=_dataService.GetFoos();
}
}
When I resolve my MainViewModel when I call
SimpleIoc.Default.GetInstance<MainViewModel>()
what happens internally is that the SimpleIoc checks to see if the MainViewModel has any dependencies (parameters in its constructor). It then tries to resolve these parameters by looking at the interfaces that have been registered with it. It does this recursively, so if DataService had a dependency it would be instantiated and passed to the DataService constructor when it was being instantiated as well.
Why would I do all this work?
- Make your classes easily unit testable
- Make your code interface-driven. This means that you're referencing interfaces rather than concrete classes
- Make your code loosely coupled. This means that someone can change the implementation of an interface and classes that consume that interface don't care and don't have to be re-coded.
- Resolve your classes dependencies in an automated way.
- In MVVM Light, you'll see that it can tell when it's running in design-mode (
ViewModelBase.IsInDesignModeStatic
), this means that you can create design-time services to provide your viewmodels data so your View in Visual Studio contains actual data.