2

A colleague of mine doesn't want to bind from the View directly to the Model. For example, in the Model, he has a ObservableCollection and in the View he wants to use it. Instead of directly using it like I would do it (e.g. {Binding Model.Collection} he has another ObservableCollection in the ViewModel which has exactly the same data as the ObservableCollection in the Model. He is synchronizing both ObservableCollections with each other through events.

What are the benefits of his approach? I, personally, disapprove of his approach because it just adds duplicate code and since you have to synchronize the ObservableCollections yourself it's also more error prone. My colleague says he wants to do it this way because then he can change the Model without changing the View.

EDIT:

Some highly upvoted answers [1][2][3] support my in my thinking that it's really okay to bind directly to the Model.

Cœur
  • 37,241
  • 25
  • 195
  • 267
gartenriese
  • 4,131
  • 6
  • 36
  • 60

2 Answers2

4

It all comes down to code separation and reusability. Ideally, the View should be completely separated from the Model. If the View doesn’t rely on a specific implementation of the Model, then it can be reused with a different model to present some other data.

So, suppose you have a AlbumView and your current Model is Album, but in future you have decided to also add Movie or Book to you library. you could still use the same AlbumViewo display your movie and book objects. Furthermore, if you want to create a new project that has something to do with albums, you could simply reuse your Album class, because it’s not dependent on any view. That’s the strength of MVVM or MVC.

So for me, I would say, that your colleague is right, because Model naturally reflect the Data Access Layer Entity, where it will be stored and handled. In addition to that, Model may have more properties related to Access data layer such as created indexing. While you ViewModel is only related to the view and the presentation logic of your application. It only reflect what the user is going to see.

Nadeem Khoury
  • 886
  • 6
  • 18
  • "Furthermore, if you want to create a new project that has something to do with albums, you could simply reuse your Album class, because it’s not dependent on any view. " But that's the case with both our approaches. Also I thought the point of MVVM was the reusability of Models, not of Views. I always thought "different Model -> different View; different View -> same Model". – gartenriese Oct 28 '16 at 11:06
2

I would say using an ObservableCollection in the Model layer is wrong. By adding that you are basically saying "Model object stores data and notifies when it changes".

The role of the ViewModel is to manipulate the Model and provide an interface to the View for presenting the Model.

I believe your colleague is right because he is enforcing separation of concerns such that manipulating the Model should not impact the View.

toadflakz
  • 7,764
  • 1
  • 27
  • 40
  • "By adding that you are basically saying "Model object stores data and notifies when it changes"." But somehow you have to notify someone (either the View or the ViewModel) of the changes. – gartenriese Oct 28 '16 at 11:12
  • No, the changes should be done through the ViewModel. – toadflakz Oct 28 '16 at 12:28
  • But why should the ViewModel know about the internal business logic of the Model? – gartenriese Oct 28 '16 at 12:47
  • I don't agree with that. The ViewModel should not need to know about how the Model gets its data, be it through a database or XML files or something else. If some data in my database changes, the change should go directly to the Model, not through the ViewModel first. – gartenriese Oct 28 '16 at 13:43
  • Indeed. If we're talking a UI presentation pattern, MVVM (which we are) then all changes must go from View to VM to Model. The VM layer may respond to some other input from other process coordinators but having a dumb Model/DAL entity implement notifications is breaking pattern. There is a difference between talking about "the Model" and talking individual Model entities in MVVM. – toadflakz Oct 28 '16 at 13:47
  • Ah, okay, I guess it was just a misunderstanding then if we're talking about different kind of "models" :) – gartenriese Oct 28 '16 at 13:55