13

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

Community
  • 1
  • 1
Jeffrey Knight
  • 5,888
  • 7
  • 39
  • 49
  • Why would the split not have worked? It's the same code and so long as the access levels is correct there should be no problem. A better test of your VM layer is can you attach a different UI to it, like Silverlight, or even run your app entirely from a unit test. – Cameron MacFarland May 10 '09 at 23:31
  • "Why would the split not have worked" - that's exactly my question. Are there any technical gotchas here ? – Jeffrey Knight May 11 '09 at 14:29
  • What is the pro of doing this? It seems unneccessary unless you literally need to use the model in another project. – rollsch Feb 20 '17 at 22:32

4 Answers4

7

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.

animuson
  • 53,861
  • 28
  • 137
  • 147
jbe
  • 6,976
  • 1
  • 43
  • 34
4

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

MarioH
  • 1,165
  • 2
  • 9
  • 15
3

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

Jeffrey Knight
  • 5,888
  • 7
  • 39
  • 49
1

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.

Ignacio Soler Garcia
  • 21,122
  • 31
  • 128
  • 207