This may be old news but back in March 2009, Shawn Wildermuth, his 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 Shawn would go this way: what Shawn 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?
