One point i want to make is: Can't we make the choice about the type of Container configurable… !!!

Thanks!!!

Thanks you…..

Also, there is no support in Blend to add d:DataContext. This has to be done in XAML. This doesn't sound like a huge deal, but when you work with designers and try to initiate them to Blend, you try to avoid having to do anything in XAML. Note however that if this is really the best solution, why not, but I have the feeling that there are other ways. This is why I am still working on that and trying to improve the ViewModelLocator.

The weird thing with the solution you proposed is that the behavior was not executed at all in Blend. This is unusual. I was busy with something else this weekend, but I will definitely dig in deeper. If the behavior was working, it would be a good solution I think. That said, I worked on implementing the super simple IOC container we talked about, and made good progress. I see a lot of value into that. OK it's not really an IOC container, and as we discussed, I think it will be rather not used outside of its primary purpose to create and locate VMs. But it is small, unobtrusive and does the job.

Cheers,

Laurent

I guess the reason could be related to the fact that the IoC mappings are missing at the moment blend construct control so I’ll try  to add lazy inti call  to IoCBuilder.CollectViewAndViewModelMappings(); in the behavior itself – guess that migh do the trick.

Will report tomorrow what happened…

And so I go back to the drawing board

Cheers,

Laurent

1) Yes you are right, I missed that. I didn't have time to check the code, and I mistakenly interpreted the first code segment in your blog post. Sorry about that. The approach makes sense.

2) We both agree.

3) IOC… I do see your point, but how easy is it if someone wants to use another IOC container instead of Unity (like in your example). Maybe we should take that on email… I am curious because I want to avoid forcing one IOC container rather than another.

As you might know, I am not satisfied with the ViewModelLocator as MVVM Light has it in V3. I am looking for better solutions. I have some ideas, and this here is definitely helping.

My email is laurent (at) galasoft (dot) ch, Can you drop me a line?

Thanks,

Laurent

first of all thank you for spending some of your VERY valuable time on reviewing the Naked MVVM

Based on some of your comments I not sure if you had time to look at the code itself so please let me clarify couple of things mentioned in your remarks which I believe are not correct and/or accurate statements.

(1)

There is no FrameworkElement neither inside of the ViewModel nor elsewhere in the code. The only place where it appears is inside of the behavior itself. Testing the 4 line of that behavior doesn’t make any sense to me, and testing ViewModel (the part of MVVM triangle which needs to be unit tested) is not requiring it also. Just check the last code listing in this blog post to see how the ViewModel looks like.

In case you still think that your statement is correct, can you please point to where in code sample we can see that inappropriate dependency

(2)

I agree with you that a base view model is a good practice and in fact I do have one similar to your ViewModelBase. The reason why I have omitted it from the post is to emphasize that initializing MVVM infrastructure shouldn’t rely on any functionality in any base VM class.   Base VM class should be optional (from the MVVM ‘framework’ perspective) and focused on removing code redundancy etc.  

(3)

I agree also with you that IoC container is scary for a lot of users still. That’s why the whole IoC code is dug deep into the single class fully encapsulated, so all a user has to do is call this single method in his App.xaml.cs

IoCBuilder.CollectViewAndViewModelMappings();

That’s the only thing one has to do to fill IoC container – zero knowledge and understanding of IoC required – ‘full plug & play’.

As for rolling up my own replacement for IoC container which would be baked in the code I personally don’t like that idea due to the facts that building one is not easy and the penalty for usage of the full IoC here is drop a IoC dll in bin folder and call a IoCBuilder.CollectViewAndViewModelMappings().  There are no other requirements in how to write ViewModels etc. and no IoC knowledge required at all, so using a IoC in my approach comes very close to "free lunch” type of thing.

In case you still think that your statement is correct and user does need to know IoC with this approach, can you please point to where in code sample we can see that?

I agree with you and that’s why I HAVE USED Unity in this blog post

ServiceLocator.IoC is just a Singleton instantiating UnityContainer, nothing else.

public static class ServiceLocator

   {

       public static readonly IUnityContainer IoC = new UnityContainer();

   }