We are about to write our first WPF application and are becoming familiar with the MVVM pattern. We've built many Winform applications and have an architecture that has been very successful for us. We're having a little bit of trouble translating that architecture or determining where certain pieces of our architecture fit in the MVVM model.
Historically we have a Gui (the main exe) that then communicates to a BusinessLogic dll. The BusinessLogic communicates to a DAL dll through a web service and the DAL interacts with the DB. The DAL, BusinessLogic and GUI all reference the same BusinessObjects dll.
Some of the transition to MVVM is fairly straight forward. Our Gui will still contain the views, our BusinessOjbects will still contain the model and our DAL will still interact with the DB (although the technology to implement them may change).
What we're not sure of is our BusinessLogic component. Historically this would provide functions for the GUI to call to then populate controls in the views (ie. GetCustomerList which would return a list of Customer objects or the typical CRUD functions).
The main hang up we have is whether the MVVM pattern would call for an additional component to house the ViewModels or if we just change our thinking and migrate what we have used as our BusinessLogic component to the ViewModels?
Does our BusinessLogic component represent the ViewModels?
Best Answer
In general, I would not place business logic in the view model layer. But the term "Business Logic" is misleading.
Eric Evans uses a model where business logic is divided into two categories
He mentions the example of an accounting application. Rules about accounts, posts, tax accounts, etc. are domain rules, rules pertaining to the domain of accounting. Logic about CSV import/export has nothing to do with the domain of accounting. These rules exists purely because we are building a software application. These are examples of application logic.
Domain rules should NEVER go into the view model layer. If you are following the MVVM pattern, then the domain rules go, without question, in the model layer.
Application rules, like CSV import/export, could go in the view model layer. But personally, I would prefer to separate that out into a separate application logic layer.
The View Model should be very simple. Looking up the data needed by the view in the corresponding model, updating the model when the view changes, listening to events in the model, and propagating those events to the view, allowing the view to be updated when the model is updated behind the scenes (if applicable).
Personally I would make sure that the view model layer contains only one type of logic, presentation logic.