MVVM, should I put logic in model or view-model (controller)

2
votes

I am new to MVVM and now doing some MVVM refactorying work on a silverlight project, suppose it is a book shopping application.

The View is a book list, I bind the title of the books to the ViewModel. So I have a public string Title { get; set; } in ViewModel, also a public string Title { get; set; } in　Model (am I right?)

Now I want put a event handler to update the book title, should I put the event handler in ViewModel or Model? and what is the Model used for?

2
silverlightmodel-view-controllermvvm

2 Answers

8
votes

In my opinion "Neither"... Add controller classes to the mix of MVVM instead.

The problem with putting controller code in view models is that is makes them harder to test independantly. In many ways I see this as just as bad as code behind.

It seems to me that everyone assumes MVVM has no controllers as they left out the C. MVVM is really a variation of MVC "that just adds ViewModels".

Maybe it should have been called MVCVM instead?

ViewModels are only there to offload the "GUI" code from the view and to contain any data for binding. ViewModels should not do any processing. A good test is that your ViewModel is testable via automated unit tests and has no dependencies on data sources etc. They should have no idea where the data is actually coming from (or who is displaying it).

Although it can be overlooked/avoided, a Controller should be responsible for deciding what data model to display and in which views. The ViewModel is a bridge between Models (the M in MVVM) and Views. This allows simpler "separated" XAML authoring.

The pattern we are using successfully on all recent projects is to register controllers only, in modules, and initialise them at startup. The controllers are very light/slim and the only thing that needs to hang around for the life of the app listening for, or sending, messages. In their initialise methods they then register anything they need to own (views and viewmodels etc). This lightweight logic-only-in-memory pattern makes for slimmer apps too (e.g. better for WP7).

The basic rules we follow are:

  • Controllers make decisions based on events
  • Controllers fetch data and place it in appropriate View Model properties
  • Controllers set ICommand properties of View Models to intercept events
  • Controllers make views appear (if not implied elsewhere)
  • View Models are "dumb". They hold data for binding and nothing else
  • Views know they display a certain shape of data, but have no idea where it comes from

The last two points are the ones you should never break or separation of concerns goes out the window.

2
votes

In simplest terms, the Model is the 'real' underlying data model - containing all the info for the booklist that might be needed by the application, able to get and set data from your database.

The ViewModel is an object that exists primarily to provide data binding for your View. It might be a subset of the Model, or it might combine properties from multiple Models into a single object. It should contain the necessary and sufficient properties to allow the View to do its job.

If the event handler relates to the View, then it belongs in the ViewModel. You might try using the Command Pattern (see Custom WPF command pattern example) if it fits your purpose.