MVVM with MEF in WPF

My goal is to program a flexible WPF application. It should be extensible via MEF. The application should be similar to the project "XFileExplorer" in the examples of MEF (preview 9) but with the MVVM pattern.

In the question I asked before I asked how I can have a ViewModel and a View which have no dependencies between each other. It should also be possible to test the application via unit testing.
Therefore we can not have dependencies between the view and the ViewModel. Such that we can not set the DataContext ni the Code-Behind file of the View.

My first idea was that the catalog has access to the ViewModel. But this is not so so simple. Attributes aren't good because they have to load the class. To edit the assembly in the client application (Activator.CreateInstance) (connect the view with the viewmodel)
is also not good because we obtain these references. A controller like in
WAF is the worst idea.

What is the best solution to implement an WPF-MVVM-MEFy application? How do i implement it the best way?

From a testability standpoint the primary focus is the ViewModel rather than the Views. Your models should contain the bulk of your UI business logic and designed in such a way that they can be tested. User controls (the view) should have minimal logic which
only relates specifically to UI concerns. In general you won't need any code in the code-behind as most UI concerns can be addressed through databinding to the ViewModel or through commanding.

You can achieve decoupling between the View and the ViewModel by using MEF. There's several different approaches to achieving this. The approach you choose really depends largely on preference. I'll list a few of them below.

1. Import the ViewModel into the View. The simplest way to do this is to have your UserControl import it's ViewModel and set the datacontext. In general having the View import a concrete ViewModel is absolutely fine as it does not creating coupling from
the ViewModel to the view, which inhibits testabilty. In the first example below, MainView is importing MainViewModel and setting it's DataContext.

Above you can see that app now imports MainViewModel. The ViewModel model imports IMainView an interface that MainView exports. The VM then passes itself to the View by calling the SetViewModel method. This style of wireup is more simliar to an MVP (Model
View Presenter) style of wire-up. The advantage of this style is it allows the ViewModel to drive everything. Disadvantage is it's more work to setup the plumbing. It also tends to be less designer (VS Designer) friendly since data will never show in the designer
unless the ViewModel is set.

3. Have a seperate class import the View and the ViewModel and marry them together.

Above the app is importing MainView and ViewModel and wiring them together. The advantage of this approach is it completely decouples the View and ViewModel from one another. Disadvantage is it requires the app (or whoever creates the view) to do the wiring,
and it is also not as desing friendly.

I resorted to use the View first approach and solved some of my issues using a ViewModel proxy/locator. So ignore the following.

[/edited]

Glen, is it possible to inject the ViewModel into the resources of the View with any of those approaches, so that we can reference it with StaticReference?
Having the ViewModel as the DataContext is nice, but in Silverlight we also need StaticReference(s) to the ViewModel e.g. inside DataTemplates.

Slightly off-topic:

I'm using the ViewModel first approach (with Prism) and noticed that while it works fine at runtime, I can't get it to work at design time, because I currently see no way of programmatically adding the ViewModel
into the resources of the View before it initializes its components; which is needed in order to be accessible via StaticReference.
See http://forums.silverlight.net/forums/t/174429.aspx and http://forums.silverlight.net/forums/t/162415.aspx
Does anyone know if this scenario is considered to be supported in the future or if a workaround exists?