Good reasons NOT to place ViewModels in separate a

问题:

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

回答1:

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.

回答2:

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

回答3:

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

回答4:

The actual question is ... what are assembles for?

They are a way to separate logic making it unavailable to other code unless you add a reference, so in fact they are a way of hiding parts of code from other parts.

Given this purpose and the way you are using it I would say that you're doing it right.

Having said that I find much easier to verify that the Views do not have any code behind in code reviews and keep the views in the same assembly. Less projects = faster compile and load times.