This project has moved and is read-only. For the latest updates, please go here.

Was it reasonable to use MEF everythere in the samples?

Jun 1, 2012 at 6:39 AM

Found that Managed Extensibility Framework (MEF) has been used for wiring Views with ViewModels. Is it reasonable to use MEF for this purpose?

IMHO, explicitly creating instances of View and ViewModel and wiring them could make the code easy and wouldn't affect scalability. Views and ViewModels are not plug-ins, I haven't seen any projects what would provide completely separate sets of views for existed ViewModels.

Jun 1, 2012 at 1:38 PM

If you want to have a clean layer separation between the Presentation and Application layer then you have the Views and ViewModels in different layers.

At runtime we need the Views and ViewModels be created together. A commons solution for this problem is using the Service Locator or Dependency Injection pattern. MEF is a Framework to support these two patterns.

Jun 2, 2012 at 11:22 PM
Edited Jun 3, 2012 at 1:16 AM

Thank you for the fast response.

Could you please clarify, why you inject the View into the ViewModel? I reckon we can do the reverse and have the ViewModel injected into the View. It will mean that the ViewModel no longer has any back reference to the View. This means when unit-testing the ViewModel you don't have a view to even Mock. Additionally it makes the code cleaner, in that in the constructor of the View, it simply sets the DataContext to the ViewModel that was injected.

And another question. To make clean layer separation you could shift the interfaces (e.g. from sub-namespace Views) to a separate assembly. It would allow to remove references to the Application layer in the Presentation assembly. Why you didn't go in this way?

Jun 6, 2012 at 6:48 PM

1. Why inject the View into the ViewModel?

I inject the View into the ViewModel so that the Application layer keeps responsible for the application workflow (see Controller classes). If you go the other way round and create the ViewModel in the View then you put the workflow logic into the Presentation layer. This way the workflow logic is highly coupled with the Views and so it is quite impossible to write unit test for this.

2. Why not creating an own “interface” assembly and remove the Application layer reference

The Presentation layer uses much more from the Application layer than only the IView interfaces. But it wouldn’t make the separation more “clean” anyway (see Architecture documentation).

Jun 6, 2012 at 10:36 PM

Now I got it. Thank you very much!