WFP MVVM: Good reasons *not* to place VM's in separate assembly?

Question

I'm developing a project using the MVVM pattern in WPF.

One of the key benefits to MVVM is maintaining clear separation between business logic and presentation.

As a test to see how well separated everything actually was, over the weekend I spiked moving all ViewModels, Models, and business logic to a separate .dll. The .exe was left as a thin presentation layer.

This worked, seamlessly, first try.

I've already seen benefits to keeping views (xaml, presentation) in the .exe and core logic in its own dll. For example, there's no longer any dilemma in my mind about whether code-behind in Xaml is an issue: I'm comfortable with it if it becomes necessary, since I know it's presentation specific.

So far this exe/dll separation has worked so well that my question is: Has anyone experienced any downside to this approach?

Related question: Implementing MVVM in WPF without using System.Windows.Input.ICommand

Answer 1

I don't see any spcific issues with this approach besides the general pro/con for using few/many projects.

Answer 2

2 weeks now with my Model & View Models in a dll, my xaml in an exe and no problems whatsoever.

Answer 3

We use this kind of separation in all of our products because it helps us to see if any code violates against the UI - business logic separation.

Most times we do it the same way as you have suggested:

• Sample.Presentation.exe (Contains all the WPF stuff, thin assembly)

• Sample.Applications.dll (Is responsible to the application's workflow, here are all ViewModels)

• Sample.Domain.dll (Here are the business rules)

We don't have encountered any issues yet and I don't expect to see any problems in future.

If you are interested in a sample application then you might have a look here:

WPF Application Framework (WAF) - http://waf.codeplex.com