MEFfing up a MVVM/CSLA example (Part 2)

In Part 1, we created all the necessary groundwork for a (simple) MVVM/CSLA implementation using MEF. In summary we created:

• The Model interfaces & classes (ITelephoneList, TelephoneList and TelephoneInfo).
• Interfaces for our View and ViewModel classes (ITelephonesView and ITelephonesViewModel).
• A concrete ViewModel class(TelephonesViewModel).
• A base and concrete ViewModelLocator class (ViewModelLocatorBase and TelephonesViewModelLocator respectively).
• Imported the CompositionHost and PartInitializer classes to extend MEF support for WPF.

OK now I remember...

Lets move to the View. Add a UserControl (TelephonesView) with the following XAML:



And in the code-behind:



The view exports itself as an ITelephonesView type. When MEF resolves a new instance, a new instance of TelephonesViewModelLocator will be created. At runtime, the locator will satisfy all its imports, which includes the ViewModel of type ITelephonesViewModel, allowing the View to use it as the DataContext and access its Model (which will also be resolved by MEF by injecting the Model's factory into the ViewModel's ImportingConstructor decorated constructor).

Creating the shell

For this example, the shell will ask MEF to import a ITelephonesView part and export itself as a Shell type. The XAML:



And the codebehind:



And finally, the ViewModel of our shell:



OK I am bored now...

We are nearly there. The last thing we need to do is setup (bootstrap?) MEF. We do this in the App.xaml.cs code-behind:



If you now launch your application, MEF should setup its container and resolve a new instance of the TelephonesView, satisfying all the dependencies as described above and adding it in your Shell's StackPanel. Also, if you open TelephonesView in either Blend or the VS designer surface, you should get everything rendering just fine.

Aftermath

This example is quite a simplified one so any conclusions should be taken with a punch of salt. There are certain things that I like about this MEF approach. Defining imports/exports feels more natural than injecting instances in different classes, since the "chaining" of object creation is awesome and can be extended a lot. On the other hand, the fact that an extra base class (ViewModelLocatorBase and n ViewModelLocator classes really spoilt the picture for me. Of course, this is not a MEF shortcoming but mine, though I could not figure a way around not having the locator classes.

For now though, I don't envisage using this pattern. It will be interesting to see what the next drop of Composite WPF will bring as far as MEF is concerned and then would be a good time to revisit.

Debugging design time issues (and how F1 can sometimes be useful)

I was going through one of my projects and fixing any blendability issues I encountered. But things went a bit pear shaped and I started getting design time errors. Damn, I thought, what could possibly have gone wrong?

1. Did I miss something from my own example?
2. Is my example wrong? (that would just be typical...)
3. Is something else I did not take into account go wrong?

Thankfully, I managed to avoid embarrassment as it was the 3rd point that was the case. In the default constructor of my ViewModel (the one invoked during design time) I had a silly error. But that is not the point of this post. The point is how did I discover it.

So how do you fix design time issues?

This may be old news to many but I never knew how to do debug during design time. This is explained adequatly well but I did get a bit confused getting it to work.

First, lets assume the following project structure:

• MyApp (Shell project)
• MyApp.Infrastructure (Infrastructure project, includes the ViewModelBehavior class)
• MyApp.Modules.Test (just a test module)

In MyApp.Modules.Test add the usual loader class and the View and ViewModel classes (TestView and TestViewModel) along with their interfaces (ITestView and ITestViewModel) and connect them using the above example. In the constructor of the ViewModel, throw any odd exception. Now your designer will throw a mystical error and will not render. Help!

The table below shows the step by step instructions of how to debug this. There are two columns, one per Visual Studio instance, and is in a timeline format.

Step	Instance 1 (debugger instance)	Instance 2 (debug triggering instance)
1	Right click on MyApp.Modules.Test then Properties-->Debug. In the Start Action group, select Start external program and locate the Visual Studio executable (usually in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe).
2	Right click on MyApp.Modules.Test and Set as Startup Project.
3	Press F5.	New instance of VS will be launched.
4		Open your MyApp solution.
5		Open the TestView view.
6	The debugger will hit the breakpoint in the constructor of TestViewModel.

And at that stage you should be able to fix any problem(s) (e.g. comment out the exception ;-) ).

The moral of the story here is not to mock the F1/Help functionality. I cannot remember the last (first?) time I used it but for some strange reason I decided to click on the Help on the designer surface when I was having problems. Following the steps I managed to locate the above linked article in the help and discover this cool little trick.

Great stuff.

MEFfing up a MVVM/CSLA example (Part 1)

MEF appears set to be the next big player in the .Net toolset. The next drop of PRISM looks like it will integrate MEF more, making the question of when to use an IoC and when to use MEF all the more unclear. A quick search with Google or StackOverflow returns many results but here is one that summarizes it quite well.

So it would look like in an MVVM scenario, the IoC approach is more appropriate. But I wanted to see the difference in action, in order to compare results. So lets see one possible way of building a View and associating a ViewModel and Model using MEF and how it fares against a possible IoC approach.

Requirements

For this test I set out the following requirements:

• Start building the chain of objects (parts) using View first.
• Use interfaces throughout.
• Make the view Blendable.

So the idea is that our main Window will import a UserControl, the UserControl will import the ViewModel and the ViewModel imports the model.

Setting everything up

First, lets create a simple CSLA readonly list to serve as out Model. Notice that what is exported is a factory delegate rather than the type itself (just one way of doing this), an idea inspired by a question asked at StackOverflow:



On the UI side, the contracts for the View and the ViewModel:



The implementation of the ViewModel:



A couple of things to note here. First, the way we load the model using the imported factory (similar idea used in a previous IoC example), asking MEF to use the constructor with the import by attributing it with ImportingConstructor. The second thing is the default constructor. If that was not in place, we would not have a fully blendable view. I will explain this more later but for now just remember that the Model will need to be loaded properly in the default constructor and this is done purely for design time convenience.

Where it starts to get a bit ugly.

At this point, we need to somehow import an instance of the ViewModel into our View (in XAML), which first needs to import the TelephoneList factory. It appears some functionality to facilitate and improve this process is in the pipeline for MEF, but for now the best approach I could come up with is to use a locator (idea inspired by this blog post). The locator will return a ViewModel instance depending on the mode (design or runtime) we are currently in. The full source of this class is:



This allows us to extend the locator class once per ViewModel (the ugly bit) but also let us import the instance at runtime or create a "dummy" instance at design time (the nice bit). Following from where we left the example, the implementation of an ITelephonesViewModel locator would look like this:



Where is PartInitializer?

Not sure if I mentioned this thus far, but the example was build in WPF (I am going completely SL when VS2010 and SL4 are properly released!). But the latest release of MEF for the desktop does not contain the PartInitializer class so what happened here?

It turns out that Glenn Block provided a desktop implementation. You can download the sample solution and include the required files (CompositionHost.cs and PartInitializer.cs) in your solution. Not sure if this will eventually be introduced in MEF but it works fine nevertheless.

And at this point I will leave you on a cliffhanger ending. The post is quite long so will break it in 2 parts. In Part 2 we will get a complete working example and compare it with the more "traditional" IoC approach.

Unity 2 and InjectionFactory

Unity 2 has now reached Beta 1 stage, which is available for download. One nice new feature is the InjectionFactory, which replaces the old and rather cumbersome StaticFactory.StaticFactoryExtension. David Hayden wrote a nice article explaining the details of it. I wanted to tweak that example in order to get Unity to resolve CSLA classes by calling their factory methods.

Setup

Lets create a quick and simple CSLA Customer class that implements a simple ICustomer interface:



If we want Unity to resolve a new Customer then we can simply do the following:



And the hard coded name "New Andreas" should appear in your console/output window.

Passing parameters to the static factory methods

This is fairly simple if your factories do not accept any parameters but is a bit trickier otherwise. Customer has also got a GetCustomer method which accepts an Id integer. One way of getting around this is to create a dedicated factory which we could call directly or inject into our container. In general though this adds an extra class (and potentially interface), which would be nice to avoid. So instead, we will add a delegate factory to our Customer class:



The delegate will serve a dual purpose here. First, it will be the factory that will be injected into the container and secondly, it will be responsible for either creating a new or fetching an existing customer, depending on weather the id parameter is empty or not. Back to our container setup:



And yep, you guessed it right. The output is:

Id:-1, Name:New Andreas
Id:3, Name:Old Andreas

Can I have a more real world example please?

That would be a bit too far fetched, but lets see how we could use this in conjunction with a ViewModelBase derived class. In this case, we will be injecting the customer factory to the ViewModel and let it update its Model when required.

To start off with, we add the constructor and properties:



Instead of calling the DoRefresh method on the ViewModel base class, we will assume control of loading the Model. This is done in the OnContextChanged handler (which is very similar to the implementation of BeginRefresh in the base class):



So now, when resolving a ViewModel:



And you can see the result on the console is what we expected it to be.

There are some parts of this solution which are not elegant. The DynamicInvoke call is a bit fragile and the fact we do not use DoRefresh or BeginRefresh is a shame. But this solution does provide some benefits as far as testability is concerned.

Fixing Blendability issues

Hardly a real word, but Blendability is quite an important issue you will need to address if you work on a large project and/or if a designed is involved. Currently, I do not have the luxury of a designer and have not yet got a Blend license so most (all?) my XAML Pages/UserControls where... umm Unblendable :-) This is evident in this previous post. But one should never shy away from fixing a problem so here is a fix, following from the previous post.

Differentiating behavior if in design mode

The following idea was inspired by one of many blendable View-ViewModel examples out there. It is evident that in order to get the VS designer and Blend to accept our ViewModel, we will need to allow XAML to get a concrete instance of it during design mode. Lets start with a simple way of determining if we are in design mode. In the ViewModelBehavior class:



Now, in the ModelAttached handler we can use the above method to resolve an instance of the ViewModel both at design and run time:



But how do create a concrete instance of a ViewModel class?

At this stage, the DependencyPropertyChangedEventArgs args parameter will contain the fully qualified type of the interface of our VM. The catch here is to make an assumption. All VM interfaces (e.g. IResourceListViewModel) have a corresponding concrete class (e.g. ResourceListViewModel) within the same namespace. If this is not the case you will have to find a different way of creating instances of VMs that implement your interface. So AttachDesignTimeModel looks like this:



The body of the method is very similar to the action assigned to the closure from within our bootstrapper (which will be executed at runtime). Using a simple LINQ query, the type of the VM is resolved and a new instance is created. There is 1 more catch here, the VM must have a public parameterless constructor defined, in order for Activator.CreateInstance to be able to create an instance at design time.

And this is it!

If you build your solution and open a view which uses the above behavior to create and attach a VM it should work fine both at run and design time. Not bad even though there are 2 catches:

1. VM classes need to be located in the exact same namespace like the interface they implement.


2. The VM needs a parameterless public constructor (only used during design time).

And another thing...

This all works well but the check on the design mode can lead you into trouble in a high volume production environment as the folks over at CSLA have discovered. Since it is unnecessary overhead anyway, you can wrap the whole code in the DEBUG compiler directive to only have active during development:



Happy designing!

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.