Model-View-ViewModel pattern violation of DRY?

Question

I read this article today http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx about the use of the MVVM pattern within a silverlight app where you have your domain entities and view spesific entities which basically is a subset of the real entity objects. Isn't this a clear violation of the DRY principle? and if so how can you deal with it in a nice way?

Answer 1

DRY is a principle, not a hard rule. You are a human and can differentiate. E.g. If DRY really was a hard rule you would never assign the same value to two different variables. I guess in any non trivial program you would have more than one variable containing the value 0.

Generally speaking: DRY does usually not apply to data. Those view specific entities would probably only be data transfer objects without any noteworthy logic. Data may be duplicated for all kinds of reasons.

Answer 2

Personally, I don't like what Dino's doing there and I wouldn't approach the problem the same way. I usually think of a VM as a filtered, grouped and sorted collections of Model classes. A VM to me is a direct mapping to the View, so I might create a NewOrderViewModel class that has multiple CollectionViews used by the View (maybe one CV for Customers and another CV for Products, probably both filtered). Creating an entirely new VM class for every class in the Model does violate DRY in my opinion. I would rather use derivation or partial classes to augment the Model where necessary, adding in View specific (often calculated) properties. IMO .NET RIA Services is an excellent implementation of combining M and VM data with the added bonus that it's usable in on both the client and the server. Dino's a brilliant guy, but way to call him out on this one.

Answer 3

I think the answer really depends on what you feel should be in the ViewModel. For me the ViewModel represents the model of the screen currently being displayed.

So for something like a ViewCategoryViewModel, I don't have a duplication of the fields in Category. I expose a Category object as a property on the ViewModel (under say "SelectedCategory"), any other data the view needs to display and the Commands that screen can take.

There will always be some similarity between the domain model and the view model, but it all comes down to how you choose to create the ViewModel.

Answer 4

It's the same as with Data Transfer Objects (DTO).

The domain for those two object types is different, so it's not a violation of DRY.

Consider the following example:

class Customer
{
    public int Age
}

And a corsponding view model:

class CustomerViewModel
{
    public string Age;

    // WPF validation code is going to be a bit more complicated:
    public bool IsValid() 
    {
        return string.IsNullOrEmpty(Age) == false;
    }
}

Differnt domains - differnet property types - different objects.