Composition Root in MVVM DDD application

2
votes

So, the answer should be pretty simple: as Mark Seemann wrote here:

A Composition Root is a (preferably) unique location in an application where modules are composed together. ( ... ) In WPF applications it's the Application.OnStartup method

I'm not sure about that OnStartup method though. Let's say we have an application consisting of these projects with dependencies:

Domain <- App Services <- WPF Client (ViewModels PCL <- Executable WPF Client with Views)

MVVM pattern says that business logic should be proceeded in ViewModel. (EDIT: Ahh, I put it in wrong words:/ What I meant is: When you have business logic (in domain) in class Game, and it has method Move which returns true if the move finished the game - you don't need Game in your View. You need a Command - MoveCommand and Game in ViewModel. And View should know ONLY about that command ). View should only know what command, from which ViewModel has to be performed. So basically, View should ONLY know about ViewModel. Knowledge about Domain is useless in View.

So my question is: Which MVVM approach should I take?

  • I want to keep best practices and create every object in composition root
  • I want to have my business objects in view models, not in view

Is ViewModel-first (or MVVMC) the only approach that could work?

1
c#.netwpfmvvm

1 Answers

1
votes

MVVM pattern says that business logic should be proceeded in ViewModel.

This one is completely wrong. You never put business logic into the ViewModel. ViewModel is presentation, so only presentation logic goes in here (input validation, controlling when and which element gets displayed or hidden and which commands exist for the user to execute on a certain event or wire up your domain objects, similar to what you do inside controller actions in MVC).

Business Logic is clearly part of your domain and should never leave the domain.

ViewModels only prepare the data of the domain (model layer; the M of MVVM) for the view to easily consume it.

I want to keep best practices and create every object in composition root

Application.OnStartup is still the right place to do it, since the application layer (in n-tier terms) is the only layer that knows about everything (ViewModels, Model, Domain and Infrastructure) and you can do your application specific configuration there, for example adding an IUserRepository could be a SqlServerUserRepository on desktop and an SqliteUserRepository on an UWP app, since SQL Server isn't available there.