4 ms·

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 st

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.

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.