1

If I have a PersonWindow and its corresponding PersonWindowViewModel and considering that this view will be used to show a collection of Person, how should I implement the exposed collection?

As a ObservableCollection<Person> or as ObservableCollection<PersonViewModel>?

In short, should I create a ViewModel for each entity that I want to represent in the View (one per view + one per model class)?

SuperJMN
  • 13,110
  • 16
  • 86
  • 185
  • Nope .. a viewmodel per view is pretty much standard .. you decide what aspects of the entities you want in the viewmodel and this decision depends on the view. – scartag Nov 02 '14 at 12:38
  • But I also have seen many times that some people wrap their models into a ViewModel (like PersonViewModel). Is it right? If so, in which situations you should choose to do this? – SuperJMN Nov 02 '14 at 12:41
  • 1
    If the view is only relevant to Person related stuff .. then you could do that .. but if you have multiple entities you are dealing with .. not sure wrapping each one in its own viewmodel makes sense .. the ViewModel as its name implies is FOR the VIEW. – scartag Nov 02 '14 at 12:44
  • 3
    Wrap your Model in ViewModel in case additional functionality required by the View (additional properties, commands, data conversions, etc.), use it as-is otherwise. – galenus Nov 02 '14 at 12:45

1 Answers1

3

I find I usually end up wrapping most of my Models in a ViewModel if they're going to be used extensively in the View, as it gives me the most flexibility.

If a Model is only used as the component of another Model, and doesn't itself have any particularly interesting display properties/logic, I'm usually happy to expose its properties via other ViewModels. It's usually a judgment call based on what you'll be doing with your models.

In your case it sounds like you may be interrogating/displaying a Person quite frequently, so you may have something like the following:

Mockup

If that's the case, I'd be inclined, as galenus suggested, to wrap each Person in a ViewModel and hold a list of ObservableCollection<PersonViewModel> on whatever ViewModel you're composing.

That way, if you need any View specific fields for displaying a Person (or additional logic), you're free to stick them on the PersonViewModel, without polluting the Person Model.

If however, all you're doing is displaying a list of Persons in a small place in your application, I probably wouldn't bother wrapping them.

I find MVVM is often a balancing act, eventually you get a feel for what is likely to require a ViewModel. Personally, I probably favour a ViewModel wrapper more than I need to, because I've often found that later in development, I require the additional flexibility.

Chris
  • 8,268
  • 3
  • 33
  • 46
  • Thanks @Chris. As you mention, sometimes you have 2 kinds of artifacts to represent the same thing. This produces duplication. Although it's not a good deal (duplication is the root of all evil) I see 2 different contexts (Model and UI), so it's OK. However, I have a big concern: synchronization between Model and ViewModel. The doubt I have is whether the wrapper ViewModel should expose the Model itself (publicly) or guard it fiercely in order to keep it consistent, intercepting anything from the outside and modifying the Model accordingly. What do you think? – SuperJMN Nov 02 '14 at 21:24
  • 1
    I'm quite a fan of guarding the `Model` properties with the `ViewModel` and taking care of the property change notification there as well (I tend to use `Caliburn.Micro`). Exposing a lot of simple properties does create a lot of boilerplate code though, so it's another judgement call. There's quite a lot of conversation on what should go where in MVVM, Fat/Skinny `ViewModels` etc. I'm in the camp of the answer to this question: http://stackoverflow.com/questions/852441/fat-models-skinny-viewmodels-and-dumb-views-the-best-mvvm-approach. There are some great discussions on the topic around SO =D – Chris Nov 02 '14 at 22:50