5 ms·

I find MVVM very confused. In MVVM you have the Model and View layers, which I get, and also the View Model layer, which I don't. The View Model is supposed to

I find MVVM very confused. In MVVM you have the Model and View layers, which I get, and also the View Model layer, which I don't. The View Model is supposed to be UI independent, and that I don't get. The Model layer is already UI independent. There is no need for a second UI independent layer. In practice the View Model layer is written specifically to support the UI, so there is no point in making it UI independent. Some argue this is for testability. But you can already test the Model layer without the UI. Additional testing should include the UI, and should be through the UI. The motivation behind MVVM appears to be to update the UI automatically when data changes. Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) Also, data binding is best done in code (the jQuery way) as opposed to declaratively (the WPF way).

Aleman360 11y ago
From a XAML perspective: The ViewModel just adapts various Models/Services for a particular View. It converts types provided by the Model as needed, formats strings, computes progress, etc. "UI independent" just means that it should be a logical model of the View, rather than a visual model (e.g., don't expose Color or Brush properties, instead expose properties like IsSelected). So think of the View model like logical code-behind. > Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) On the web, maybe. But Windows apps (UWP) are still based on data binding.
- jsmeaton 11y ago
  I've only ever done MVVM development with WPF/XAML and it makes a whole lot of sense for me. Viewing it as a logical code-behind is exactly the right way to see view models in my experience. I've not done iOS development, and the term View Controller in the article was very confusing. Other than XAML being somewhat confusing and having relatively poor IDE support, I've found the WPF MVVM model to be the most intuitive and nice UI design pattern that I've used.
- interlocutor 11y ago
  > don't expose Color or Brush properties Why not? The ViewModel is written specifically for the View, and it does not serve any purpose to make it UI independent. By avoiding Color etc. in this layer you end with two UI independent layers (Model and ViewModel) and that makes no sense. One UI-independent layer is enough. In MVVM the View knows about the ViewModel but supposedly the ViewModel does not know about the View. But in reality the ViewModel is written specifically for the View, so it might as well know the View.
  - Aleman360 11y ago
    UI frameworks usually have DSL's that are much better at dealing with visual state (e.g., XAML, CSS) and provide mechanisms for sharing styles and resources between multiple views. And do things like swap colors out automatically based on system accessibility settings. Or adjust font sizes for localization.
- interlocutor 11y ago
  > But Windows apps (UWP) are still based on data binding. Yes, I understand that Windows APIs still use two-way data binding. But by and large the developer community is realizing that two-way data binding is gimmicky and that in large applications two-way data binding is a liability. On the Web most JavaScript frameworks are moving away from two-way data binding (React, Angular 2, Ember, etc.) The reason for that has nothing to do with the Web or with JavaScript. The underlying reason is applicable to application development in general, regardless of platform. Here's Tom Dale and Yehuda Katz, developers of Ember, explaining their decision to move away from two-way data binding: https://changelog.com/131/ https://changelog.com/131/ (skip to 0:42) Excerpts:-------------------- "Why do people still prefer to write server-rendered apps? The programming model is just so easy. If you think about how people build sever-rendered apps.. the request comes in, you get your model data out of the database, you hand it to your view layer to render, you return that output and that's it. Every time you handle a new request, because HTTP is stateless, you start from scratch. "Conversely, things like Angular and Ember have two-way data bindings, right? And it really easy to end up in -- especially in a large or sophisticated application which is stateful. As the user is looking at it, it's not like the state is getting reset, you are constantly having to keep everything in sync yourself. It is easy to end up in a state where you can't yourself explain how data flows through it. "The brilliance in react is bringing back a programming model that is as simple as server-rendered apps. "Even though both Angular and Ember have the notion of events and data bindings, data bindings feels so cool that people started tunneling events through data bindings. "Honestly when I look at the critiques React people have about Ember and trying to understand, OK, you were an ember developer, you were reasonably productive, but you find yourself way more productive in React. What is happening? What we are finding -- and this played into the Ember 2.0 plan -- is that people are abusing two way data bindings to express something that is fundamentally an event. A big focus of Ember 2.0 is moving away from two way data bindings as the primary method of communication to events. We added too much sugar around two-way data bindings and that led people to use two-way data bindings as an event bus.
Lazare 11y ago
I wrote a (very) large SPA in Knockout, which is nominally a MVVM framework, and I definitely see your points. In Knockout, you have HTML templates, which are the view, but the distinction between the Models, the View Models, and every other bit of code in your application is pretty much lost. Not sure if it was my lack of knowledge of MVVM best practices (likely), Knockout (possible), or something inherent to MVVM, but if ever there was an architecture that lent itself to turning into Big Balls Of Mud... Edit: Digging into the links, it seems the article is talking specifically about native mobile applications, so maybe there's context I'm missing.
dewiz 11y ago
>>Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) Do you have any reference about this? I thought the opposite was true. My main interest being Ember, I'd like to know more about what you said.
- edgyswingset 11y ago
  Take this as a grain of salt, but my experience with React so far as been one where it's easiest to set up your UI as one-way "data pipelines".
- petilon 11y ago
  Here it is: Creators of Ember talking about moving away from two-way data binding: https://changelog.com/131/ https://changelog.com/131/ (skip to 0:43)
MatthewPhillips 11y ago
> The motivation behind MVVM appears to be to update the UI automatically when data changes. Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) Angular still has ngModel according to its docs. Whether you have two-way binding or not, View Models are still useful. Cycle.js doesn't have two-way binding but uses Event Streams and has a pattern that is similar to MVVM (they call it Model-View-Intent but the Model is a View Model by normal definition). React not having something like MVVM makes it difficult to create reusable components. Most React apps are divided into the view layer (which are "components" but really just dumb views) and application logic which lives in the flux layer. This division means you can't / shouldn't write components that fetch their own data.
- rjayatilleka 11y ago
  Shouldn't, not can't. You still can have components keep their own state, and that may be the right decision for small/localized/ephemeral state, such as what's selected in a dropbox, or the coordinates of a widget that's being dragged around. But it's more common to have views trigger events/send actions, which then update the top-level state and trigger a re-render.
nodamage 11y ago
I get the impression that MVVM only really works well when you have robust data-binding support baked into the framework (e.g. WPF/XAML). Otherwise you end up with a bit of an impedance mismatch and a lot of overhead in keeping the views synced with the view model. For example under iOS this probably means going all-in with ReactiveCocoa. But I'm not convinced that completely switching paradigms like that is the right way to go.

Aleman360 11y ago

From a XAML perspective: The ViewModel just adapts various Models/Services for a particular View. It converts types provided by the Model as needed, formats strings, computes progress, etc. "UI independent" just means that it should be a logical model of the View, rather than a visual model (e.g., don't expose Color or Brush properties, instead expose properties like IsSelected). So think of the View model like logical code-behind. > Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) On the web, maybe. But Windows apps (UWP) are still based on data binding.

jsmeaton 11y ago
I've only ever done MVVM development with WPF/XAML and it makes a whole lot of sense for me. Viewing it as a logical code-behind is exactly the right way to see view models in my experience. I've not done iOS development, and the term View Controller in the article was very confusing. Other than XAML being somewhat confusing and having relatively poor IDE support, I've found the WPF MVVM model to be the most intuitive and nice UI design pattern that I've used.
interlocutor 11y ago
> don't expose Color or Brush properties Why not? The ViewModel is written specifically for the View, and it does not serve any purpose to make it UI independent. By avoiding Color etc. in this layer you end with two UI independent layers (Model and ViewModel) and that makes no sense. One UI-independent layer is enough. In MVVM the View knows about the ViewModel but supposedly the ViewModel does not know about the View. But in reality the ViewModel is written specifically for the View, so it might as well know the View.
- Aleman360 11y ago
  UI frameworks usually have DSL's that are much better at dealing with visual state (e.g., XAML, CSS) and provide mechanisms for sharing styles and resources between multiple views. And do things like swap colors out automatically based on system accessibility settings. Or adjust font sizes for localization.
interlocutor 11y ago
> But Windows apps (UWP) are still based on data binding. Yes, I understand that Windows APIs still use two-way data binding. But by and large the developer community is realizing that two-way data binding is gimmicky and that in large applications two-way data binding is a liability. On the Web most JavaScript frameworks are moving away from two-way data binding (React, Angular 2, Ember, etc.) The reason for that has nothing to do with the Web or with JavaScript. The underlying reason is applicable to application development in general, regardless of platform. Here's Tom Dale and Yehuda Katz, developers of Ember, explaining their decision to move away from two-way data binding: https://changelog.com/131/ https://changelog.com/131/ (skip to 0:42) Excerpts:-------------------- "Why do people still prefer to write server-rendered apps? The programming model is just so easy. If you think about how people build sever-rendered apps.. the request comes in, you get your model data out of the database, you hand it to your view layer to render, you return that output and that's it. Every time you handle a new request, because HTTP is stateless, you start from scratch. "Conversely, things like Angular and Ember have two-way data bindings, right? And it really easy to end up in -- especially in a large or sophisticated application which is stateful. As the user is looking at it, it's not like the state is getting reset, you are constantly having to keep everything in sync yourself. It is easy to end up in a state where you can't yourself explain how data flows through it. "The brilliance in react is bringing back a programming model that is as simple as server-rendered apps. "Even though both Angular and Ember have the notion of events and data bindings, data bindings feels so cool that people started tunneling events through data bindings. "Honestly when I look at the critiques React people have about Ember and trying to understand, OK, you were an ember developer, you were reasonably productive, but you find yourself way more productive in React. What is happening? What we are finding -- and this played into the Ember 2.0 plan -- is that people are abusing two way data bindings to express something that is fundamentally an event. A big focus of Ember 2.0 is moving away from two way data bindings as the primary method of communication to events. We added too much sugar around two-way data bindings and that led people to use two-way data bindings as an event bus.

Lazare 11y ago

I wrote a (very) large SPA in Knockout, which is nominally a MVVM framework, and I definitely see your points. In Knockout, you have HTML templates, which are the view, but the distinction between the Models, the View Models, and every other bit of code in your application is pretty much lost. Not sure if it was my lack of knowledge of MVVM best practices (likely), Knockout (possible), or something inherent to MVVM, but if ever there was an architecture that lent itself to turning into Big Balls Of Mud... Edit: Digging into the links, it seems the article is talking specifically about native mobile applications, so maybe there's context I'm missing.

dewiz 11y ago

>>Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) Do you have any reference about this? I thought the opposite was true. My main interest being Ember, I'd like to know more about what you said.

edgyswingset 11y ago
Take this as a grain of salt, but my experience with React so far as been one where it's easiest to set up your UI as one-way "data pipelines".
petilon 11y ago
Here it is: Creators of Ember talking about moving away from two-way data binding: https://changelog.com/131/ https://changelog.com/131/ (skip to 0:43)

MatthewPhillips 11y ago

> The motivation behind MVVM appears to be to update the UI automatically when data changes. Modern frameworks are moving away from two-way data binding (React, Angular 2.0, Ember, etc.) Angular still has ngModel according to its docs. Whether you have two-way binding or not, View Models are still useful. Cycle.js doesn't have two-way binding but uses Event Streams and has a pattern that is similar to MVVM (they call it Model-View-Intent but the Model is a View Model by normal definition). React not having something like MVVM makes it difficult to create reusable components. Most React apps are divided into the view layer (which are "components" but really just dumb views) and application logic which lives in the flux layer. This division means you can't / shouldn't write components that fetch their own data.

rjayatilleka 11y ago
Shouldn't, not can't. You still can have components keep their own state, and that may be the right decision for small/localized/ephemeral state, such as what's selected in a dropbox, or the coordinates of a widget that's being dragged around. But it's more common to have views trigger events/send actions, which then update the top-level state and trigger a re-render.

nodamage 11y ago

I get the impression that MVVM only really works well when you have robust data-binding support baked into the framework (e.g. WPF/XAML). Otherwise you end up with a bit of an impedance mismatch and a lot of overhead in keeping the views synced with the view model. For example under iOS this probably means going all-in with ReactiveCocoa. But I'm not convinced that completely switching paradigms like that is the right way to go.