Does this article violate the MSDN MVVM?

Question

This may be old news, but back in March 2009, this article “ Model-View-ViewModel In Silverlight 2 Applications ” has a sample code that includes a 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 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 is implied in this class is that the developer intends to directly bind visual data to data (yes, the ViewModel is used, but it defines an ObservableCollection of data objects). Is this design too much at odds with the MVVM manual? Now I see some reasons why we should go this way: what can we do with the DataServiceEntityBase - this is such a thing (which is closely related to 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 } 

Sure, MSDN code can be thought of as “toy code” for educational purposes, but does anyone do something similar in the real world of Silverlight development?

Answer 1

To make the View completely independent of the Model, you will need to reproduce types that in many cases are identical to the types of the model in your ViewModel.

Example

The model contains the type Person , which has the FirstName and LastName properties. The visual design requires a "List of People", so there is a view containing a ListBox that binds the data template to the FirstName and LastName property paths. ItemsSource tied to the ViewModel property, which provides many instances of types that have the FirstName and LastName properties.

So here's the question: should there be a version of the ViewModel of type Model Person or should the ViewModel reuse the existing type of Person from the Model?

In any case, it is entirely possible that you want the properties to be visible.

To consider

What are the goals of MVVM? Quite often, we like to present good long lists of why the template exists, but in this case there really are only 2.

• Separate visual design ( note : not design) from the code.
• Enlarge the test surface of the entire application.

Displaying model types in the ViewModel does not interfere with any of the above goals. In fact, this helps to test, since the number of types and members that need testing is reduced.

In my opinion, I do not see that the implementation of INotifyPropertyChanged implies binding to visual effects. There may be other reasons why some services may want to observe changes in the properties of the model object.

The key principle for separating a model from a view is to hide any features of how the view represents the model from the model itself. Adding the ForenameBackColor property to the model would probably be bad. Here is the ViewModel.

Bottom row

The requirement that the model display observable properties is not a violation of MVVM, its simple and general requirement, which does not require the Model to have any specific knowledge about any representation or really that there are any “visual effects.” p>

Answer 2

No, it looks great to me - DataServiceEntityBase is just the name of its base class, to which all its DTO objects / business objects are inherited, there is nothing wrong with this setting (is that the name?). If he puts his data in the ViewModel and then binds his View to the VM, then you have at least part of the VVM MVVM.

The main thing that I would be upset about is his FirePropertyChanged method name - personally, I would call it On PropertyChanged.