Does this MSDN article violate MVVM?

Question

This may be old news but back in March 2009, this article, “Model-View-ViewModel In Silverlight 2 Apps,” has a code sample that includes DataServiceEntityBase:

// COPIED FROM SILVERLIGHTCONTRIB Project for simplicity

/// <summary>
/// Base class for DataService Data Contract classes to implement 
/// base functionality that is needed like INotifyPropertyChanged.  
/// Add the base class in the partial class to add the implementation.
/// </summary>
public abstract class DataServiceEntityBase : INotifyPropertyChanged
{
/// <summary>
/// The handler for the registrants of the interface's event 
/// </summary>
PropertyChangedEventHandler _propertyChangedHandler;

/// <summary>
/// Allow inheritors to fire the event more simply.
/// </summary>
/// <param name="propertyName"></param>
protected void FirePropertyChanged(string propertyName)
{
  if (_propertyChangedHandler != null)
  {
    _propertyChangedHandler(this, new PropertyChangedEventArgs(propertyName));
  }
}

#region INotifyPropertyChanged Members
/// <summary>
/// The interface used to notify changes on the entity.
/// </summary>
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged
{
  add
  {
    _propertyChangedHandler += value;
  }
  remove
  {
    _propertyChangedHandler -= value;
  }
}
#endregion

What this class implies is that the developer intends to bind visuals directly to data (yes, a ViewModel is used but it defines an ObservableCollection of data objects). Is this design diverging too far from the guidance of MVVM? Now I can see some of the reasons Why would we go this way: what we can do with DataServiceEntityBase is this sort of thing (which is intimate with the Entity Framework):

// Partial Method to support the INotifyPropertyChanged interface
public partial class Game : DataServiceEntityBase
{
    #region Partial Method INotifyPropertyChanged Implementation
    // Override the Changed partial methods to implement the 
    // INotifyPropertyChanged interface

    // This helps with the Model implementation to be a mostly
    // DataBound implementation

    partial void OnDeveloperChanged() { base.FirePropertyChanged("Developer"); }
    partial void OnGenreChanged() { base.FirePropertyChanged("Genre"); }
    partial void OnListPriceChanged() { base.FirePropertyChanged("ListPrice"); }
    partial void OnListPriceCurrencyChanged() { base.FirePropertyChanged("ListPriceCurrency"); }
    partial void OnPlayerInfoChanged() { base.FirePropertyChanged("PlayerInfo"); }
    partial void OnProductDescriptionChanged() { base.FirePropertyChanged("ProductDescription"); }
    partial void OnProductIDChanged() { base.FirePropertyChanged("ProductID"); }
    partial void OnProductImageUrlChanged() { base.FirePropertyChanged("ProductImageUrl"); }
    partial void OnProductNameChanged() { base.FirePropertyChanged("ProductName"); }
    partial void OnProductTypeIDChanged() { base.FirePropertyChanged("ProductTypeID"); }
    partial void OnPublisherChanged() { base.FirePropertyChanged("Publisher"); }
    partial void OnRatingChanged() { base.FirePropertyChanged("Rating"); }
    partial void OnRatingUrlChanged() { base.FirePropertyChanged("RatingUrl"); }
    partial void OnReleaseDateChanged() { base.FirePropertyChanged("ReleaseDate"); }
    partial void OnSystemNameChanged() { base.FirePropertyChanged("SystemName"); }
    #endregion
}

Of course MSDN code can seen as “toy code” for educational purposes but is anyone doing anything like this in the real world of Silverlight development?

Answer 1

No, looks fine to me - DataServiceEntityBase is just the name of his base class which all his DTO's/business objects inherit from, nothing wrong with that setup (did that name throw you a little?). If he is putting his data in a ViewModel and then binding his View to the VM then you at least have the VVM part of MVVM.

The main thing i would be upset about is his naming of the FirePropertyChanged method - personally i would have called it OnPropertyChanged.

Answer 2

In order to make a View entirely independent of the Model you would need to reproduce types that in many cases are identical to the Model types in your ViewModel.

Example

A Model contains a Person type that have FirstName and LastName properties. The visual design calls for a "List of people" so there is a View containing a ListBox that has a data template binding to property paths of FirstName and LastName. The ItemsSource binds to a property of ViewModel that exposes a set instances of types that have a FirstName and LastName property.

So here is the question, should there be a "ViewModel version" of the Model Person type or should the ViewModel simply re-use the existing Person type from the Model?

In either case its quite possible that you would want the properties to be observable.

To consider

What are the objectives behind MVVM? Quite often we like to present nice long lists of why a pattern exists but in this case there are really only 2.

• Separate visual design (note: not design) from code.
• Maximise the testable surface of the overall application.

Exposing Model types on the ViewModel doesn't form an obstacle to either of the above objectives. In fact it aids testability since the number of types and members that need testing is reduced.

In my opinion I don't see that implementing INotifyPropertyChanged implies binding to visuals. There may be other reasons why some service may want to observe changes in properties of a model object.

The key principle in the separation of Model from View is hiding of any specifics about the how the View presents the Model from the Model itself. Adding a ForenameBackColor property to the Model would be probably be bad. This is where the ViewModel comes in.

Bottom Line

Requiring the Model to expose observable properties is not breach of MVVM, its a simple and general requirement that does not require the Model to have any specific knowledge of any View or indeed that there are any "visuals" involved at all.