MVVM Part 1: Overview

There have already been quite a few articles, HOW-TOs and tutorials to the Model-View-ViewModel (MVVM) architecture.

One of the best is WPF Apps With The Model-View-ViewModel in my opinion.

However, I have different or advanced solutions for some problems. So I’ll start a series with an unknown number of parts about this topic.

Still, I explicitly recommend reading the others, too. Only this will help you to find your interpretation of MMVM.

What is MVVM?

MVVM is a pattern that helps to separate the behavior of an User Interface from its design.

Why doing so?

There are several reasons for that:

  • Separation: UI and logic are separated for changing them without affecting the other one
  • Testing: Plain UIs can not be tested easily. ViewModels can.
  • Support of different views: You want to create multiple UIs for an application? That’s much easier
  • Ease of the use of WPF Controls: Ever tried to fill a Treeview in WPF without MVVM? It’s quite uncomfortable.
  • Taking advantage of WPF-Features like Data Templates, Data Binding and dynamic Control creation

The three players

The Model

What?

In short, the Model is the “real application”. It represents all the business logic.

Do not see the Model as something passive or as something that contains no logic!

Where are its limits?

The Model shouldn’t contain any logic to directly interact with the user. This shouldn’t be any new information.

This includes displaying of Windows / Forms / MessageBoxes but also formatting data. That’s none of their business!

Checklist

A little “checklist” for a good Model (of course, there may be exceptions here); arbitrary order:

  • Did I use no class contained in System.Windows (and inferior namespaces)? Thus, I need no reference to PresentationFramework.dll, System.Windows.Forms, PresentationCore, …?
  • Is it neither laid out for Windows Forms, nor WPF? Could I use everything in a Console Application theoretically?
  • Am I using content that needs to be translated? It’s only OK for messages that won’t displayed to the user. (Exceptions – if you prefer using localized ones – and Logfiles can be exceptions)
  • Is there no need of additional logic concerning working with my Model-classes? That means: Every kind of manipulation the application itself does to its data (e.g. functions like “Load the latest stocks from our homepage” or “Do an automatic cleanup and delete all Customers that made no order during the last year”) should be implemented here.
  • Does my Model perform validation?
  • Did I implement code to fetch objects from my data store and save it there? Is this procedure abstracted by my Model? Did I also abstract the specific queries so the user of my classes doesn’t need to know about the structure of my database?
  • Did I use events when requiring feedback from the user?

The ViewModel

Well, what is the ViewModel then?

According to my definition it is a layer which is databound to the view and prepares the model in order to be displayed by it. It does so by providing a kind of proxy classes. Thereby it simplifies complicated situations by changing the structure of the model.

What does it do?

As already said in the definition: Its main task is simplifying and restructuring data in a form that can’t be visualized directly by the view. Everything is supplied in a bindable way by implementing INotifyPropertyChanged.

Every action you can perform (this also includes object creation) is exposed as a command.

There are three “base” types of patterns: Selecting one or more items, Changing a property, Invoking a method.

Where are its limits?

The ViewModel should not know about the concrete view. Only the structure of a view is considered when creating it. By saying “structure” I neither mean the layout nor the real “looking”. “Structure” describes what a user can actually do – something like “There is a possibility to change the name of a person.” or “Items can be deleted, added, and reordered here”.

In my opinion, formatting (of primitive values – e.g. setting the number of decimal points or combining two or more properties to a new one) is also not a part of the ViewModel.

One important thing, a ViewModel should never do: Do not use classes from “System.Windows”. That means: No MessageBox.Show, no creation of Windows, …

Checklist
  • Is the ViewModel “easy” to use?
  • Does it track property changes and report them via INotifyPropertyChanged?
  • Do all properties either return another ViewModel, a primitive data type or a collection of one of these?
  • Does it not contain any String.Concats, String.Formats, … in order to combine two or more properties to a new one?
  • Are there commands for every action you can do with the ViewModel?
  • Is it independent of the current UI?
  • Did I use no classes declared in “PresentationFramework.dll” (which includes all controls)?
  • Is every action exposed as a command?

The View

What?

The view is the “real UI” or simply “that thing you can really see”. For each ViewModel there is exactly one UserControl representing it.

This UserControl is assembled out of existing controls (of course there can be user generated controls – however, these controls should be independent). It has no code-behind and only consist of XAML-Code. Data Templates, Data Binding, Styles and Resources are used to a great extent.

All formatting, arrangement and visualizing of data is done here.

Where are its limits?

Although the View displays everything, it’s designed more passive than active. It only invokes commands, and changes databound properties. It will never change something by code.

Therefore, it contains no program logic.

Checklist
  • Does the View only use the ViewModel (and not the Model) classes?
  • Is the View free of logic that affects more than the UI itself?
  • Is there exactly one UserControl per each ViewModel class?
DotNetKicks Image
Advertisements

5 Responses to “MVVM Part 1: Overview”

  1. Mr Evil Says:

    Hi,

    You say that MessageBoxes should not be shown in the Model, this makes sense in my oppinion.
    But you say also that the ViewModel also should not create MessageBoxes and Windows.
    This I don’t understand.
    Where the MessageBox should be called?
    Where the Windows should be created.
    For example, the Windows closes and the Closing Event is delegated to a ClosingCommand
    Then the user should be asked “really want to quit” – if not e.Cancel = true.
    Where this logic should be?
    Also if a “Show Settings” from the menu is called – where the Window should be created if not in the ViewModel ?

  2. winsharp93 Says:

    >> But you say also that the ViewModel also should not create MessageBoxes and Windows.
    >> Where the MessageBox should be called?
    >> Where the Windows should be created.

    Well, it’s my fault: I better should have said that I’ll introduce another way to do that – totally decoupled from the concrete view.
    Without knowing that my suggestions seem quite weird 🙂

    The syntax will be something like “this.UserInteracter.Show(…)” while Show expects a ViewModel class.

    Saying that the ViewModel may not do anything that will bring up a new UI-Element was definitly not my intention.

  3. NeXoR Says:

    Hi winSharp, Hi Mr Evil

    i think http://www.codeproject.com/KB/architecture/MVVM_Dialogs.aspx (sry, don’t know how to link in comments ;)), is a quite good solution for your request.

    But I got another question.

    >>Did I use no classes from the namespace “System.Windows”?

    In my ViewModels i got some Visibility properties, who are binded to some controls in my View based on properties in my models.
    Is this just a bad solution, or is it an exception?

    And, this blog-entry is a fine collection of things, who should be considered, if you are new to mvvm 🙂

  4. winsharp93 Says:

    >> MVVM Dialogs is a quite good solution for your request.
    Yes, my solution goes into that direction.
    You’ll see it in one or two weeks. 😉

    >> In my ViewModels i got some Visibility properties, who are binded to some controls in my View based on properties in my models.
    Thanks for pointing that out.
    Using no class out of “System.Windows” is only a best practice if you want to ensure compatibility to WinForms.
    Then, however, you couldn’t use classes as Dispatcher or ICommand.
    So I changed the “Did I use no classes from the namespace “System.Windows”?” to “Did I use no classes declared in “PresentationFramework.dll”” (which are nearly all controls) . That fits much better to my intention.

    Well Visibility is a “border-case” in my opinion. Finding a general answer for question like that is impossible.
    My personal preference is using a bool (in combination with a converter) instead, so the ViewModel does not really “hide” something on the UI but “marks” something as not active or relevant. Therefore the view may be able to decide only to mark something as inactive.

  5. Gerhard Says:

    Mr. Evil,
    when you start out opening MessageBoxes in the ViewModel classes, your VMs would only working with one specific UI. Let’s think about you start with WPF in mimd and you want later switch to Silverlight and to ‘SomethingToInvite’ after 3 more years, you have to patch your ViewModel.
    When you do it with MEFedMVVM via a service, you just add a new service with specific code to popup MessageBoxes and you were done.
    As you use MEF, you can compose your application for a lot of different UIs without do any change to running code.
    Nice, isn’t it?

    With best regards

    Gerhard


Comments are closed.

%d bloggers like this: