Resolve my ViewModel!

There are plenty of posts around the web discussing how to relate a View with a ViewModel or vice versa. All approaches have pros and cons and these are discussed (and commented on) quite extensively. In summary the options are:

• View first: The View has a relationship to its ViewModel (usually through data binding)
• ViewModel first: The ViewModel creates the View (usually through an IoC container)
• Programmatically relating the 2: There are a number of way of doing this. One example is the proposed marriage of the 2 as described in this post by Shawn Wildermuth (the above definitions are also from that post).

My arsenal of tools when creating smart clients includes CSLA and Composite WPF. Version 3.8 of CSLA introduced some helper ViewModel classes. Out of the box, the VM base classes are easy to use and resemble (to me at least) more the View first approach. So (using the ProjectTracker example of CSLA) you would have the following ViewModel:

And finally, in the view:



And this works just fine. The problem of course here is that if the ViewModel has got dependencies (e.g. to the EventAggregator) then since we are manually creating a new instance of the ViewModel, the dependency will not be resolved. One solution would be to go the ViewModel first route, let the IoC container create an instance of the required View and set the ViewModel as the DataContext of the View. But I wanted to avoid that. I wanted View first, with the ViewModel resolved by my IoC.

After a lot of searching, I decided on a hybrid approach described in the following 2 articles:

http://csharperimage.jeremylikness.com/2009/12/prism-mef-and-mvvm-part-1-of-3-unity.html#tb
http://jeffreypalermo.com/blog/constructor-over-injection-anti-pattern/

So to start off with, I created a ViewModelBehavior class and placed it in an infrastructure project, accessible by all my modules:



Then, to avoid sending a reference of our container to that class, in BootStrapper.ConfigureContainer:



So now the View would contain the following:



So when the container resolves the View, the ViewModel will eventually have its dependencies resolved as well, there is no need to code the relationship between View and ViewModel and the View is decoupled from the ViewModel (since if you noticed I used an interface type to resolve the VM - just remember to set this up in your container!)

What I did not have the chance to test yet is:

• Does this work in Silverlight.


• Will Blend play along with this.

But that is for another time!

Welcome

Hi and welcome to my blog!

This might yet be another blog about all stuff .net related. I wanted to create an area where I can gather and group my thoughts, maybe sharing them (to anyone interested), maybe helping someone (if anybody stumbles upon the same issues I will cover) or maybe getting some constructive feedback (if I upset someone with what I post!).

My main areas of interest are smart clients. I have been developing smart clients for a long time now, using CSLA as the business layer and Composite Application Block and more recently Composite WPF/. I love using such frameworks since they allow me to:

1. Learn best practices while learning new technologies
2. Deliver great solutions in less time

So that's it for an introduction. First meaningful post should follow soon.