VMLocator or IoC

May 27, 2011 at 3:16 PM

Hi Guys,

No doubts that MVVMLight is the best light toolkit (toolkit not framework, so u can use only part of it).
The problem finding ViewModel for view is solved via helper class VMLocator - you have to maintain it, and this class is sort of confusing...

I always wanted to ask, why to straggle with VMLocator if we have IoC (MVVM is part of .Net4), why not use something like this:

public class MyView {

[Import]
public MyViewVM VM {get;set;}

public MyView(){
SatisfyImports(this);
}
}

and create MyViewModel with [Export] attribute..

You might ask how to deal with design time data.. Easy (at least for me):
In MyView.xaml use
d:DataContext="{d:DesignInstance vm:MyViewMV, IsDesignTimeCreatable=True}"

and in MyViewVM.cs in constructor:
ViewModelConstructor(){
if (DesignTime=true) {GetDesignTimeData; return}
}



Using this approach you avoid creating ViewModelLocator class - so less chances to introduce error...

Laurent, you will probably read this - what would u say? I saw your interview with John Papa and u mentioned something abt introdusing light IoC in MVVMLight v.4. Is it going to work similar to my idea (Well, it is not my idea - it is prism approach -))?

Coordinator
May 27, 2011 at 3:44 PM

Hi,

The main issue with using an IOC (or in the case you describe, MEF which is something a little different) without a ViewModelLocator (VML) is Blend. Yes, you can use d:DataContext, but it is less flexible and clean than if you use the VML. Also, MEF does not work on the Windows Phone, so you end up having two different wiring systems to teach. Again, not a huge deal, but something that led me to privilege the VML.

In fact, since I started using it, I (and John Papa, amongst others) came to really like the VML as beign a place convenient to do your setup. I like creating my services there, wiring things together, it is a neat object with a single responsibility. Yes, it introduces a little overhead, one more class to manage. But for me, it makes sense.

That said, it is very much a question of preferences. some people love IOC containers, some prefer other ways, etc. It is quite the same here. Personally I like a reasonable use of IOC containers, I love MEF, etc. I use each of these techniques with pragmatism and moderation, and I totally understand if you prefer to go without the VML. Doesn't mean the code will work less good :)

To answer your question about SimpleIoc in MVVM Light V4, I use it in fact in collaboration with the VML. I use it to keep the VML code cleaner and leaner.

In the future, i have hopes that we will be able to have a more automated VML, able to resolve VMs automatically, for example based on the type of the view. In the moment however, and even though I have been trying to achieve this for a very long time, it still doesn't work well in Blend. 

Cheers,

Laurent

May 27, 2011 at 3:54 PM

Cool, famous Laurent answered -))) Silverlight TV star talks to me -))) cool.

Yeh, make sense. As you mentioned in the interview MVVM is toolkit - use what u want..

This issue bugs me because I am not sure if my (prism) approach is more efficient (efficiency for me is time for development and change / complexity) or there is more elegant way to do this - for example VML.

Anyway, thanks again.

Your fun.