MVVM Clarification

Question

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?

Answer 1

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

• Domain logic - Logic related to the actual problem domain you are solving
• Application logic - Logic related to the fact, that you are building an application

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.

Answer 2

Yes.

The business logic layer is represented by the VM layer. So just migrate your mental model.

To help with your mental model migration, one slight nuance is that the GUI (View) objects should be bound to objects within the VM layer. That binding translates into | implies that the View no longer being the layer that "makes the call" in order to retrieve something else. The call for data retrieval will come from the VM instead.

To better explain: Yes, an object within the View will need to change in order to trigger the sequence of things that will make the call. But the View doesn't make the call itself. And in this case, I consider a button click as equivalent to something within the View changing, but still not making the call.

In the first case, that View object will be bound to a VM object. The VM should be listening for a property changed event on the bound object. The object change event can then be wired to a VM function to make the Model call.

In the second case (button click event), the change (click) event can be wired to a function call exposed by the VM.

Either way, it's always an event that sequences into the VM which then calls the Model which in turn calls the DAL / DB.

I bring it up because some WinForm code is used to making a call to the DB layer directly from the code-behind of the WinForm GUI. That approach breaks the separation that MVVM is providing.

Answer 3

You are correct that you would essentially be replacing your BusinessLogic dll with your ViewModel layer, however I think the biggest difference you will face is how the View/UI layer interacts with your ViewModel/BusinessLogic layer.

In WinForms, the GUI is your application, and is responsible for application flow. In WPF/MVVM, your ViewModels are you application, and the GUI becomes just a user-friendly interface to interact with the ViewModels.

For example, with WinForms, you might have a DataGrid and a Button, and when you click that Button you call BusinessLogicLayer.GetProducts() and load the resulting Product objects into the DataGrid.

With WPF, you would have a ViewModel that contains an ObservableCollection<Products> and an ICommand GetProducts, and executing the command calls the DAL and loads the collection of products. But to provide a user-friendly interface for this, you would create a View which renders your ViewModel using a DataGrid for the Products collection, and a Button for the GetProducts command.

I actually wrote a fairly recent post for my blog about the change in mindset when moving from Winforms to WPF on my blog, and I think the best way to summarize the difference is with these pictures: