¿El MVVM es el mismo que el modelo de presentación?

Is the MVVM the same as the presentation model?

MVVM is identical to Fowler’s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View’s state and behavior.

As opposed to a passive view which has no knowledge of the model and is completely manipulated by a controller/presenter, the view in MVVM contains behaviors, events, and data-bindings that ultimately require knowledge of the underlying model and viewmodel.

There is nothing wrong with either approach, but in this article, I examine the benefits of explicitly using MVVM as the architecture of a WPF application. The names of certain classes include well-known terms from the MVVM pattern, such as ending with “ViewModel” if the class is an abstraction of a view.

MVVM: Should a VM object expose an M object directly, or only through getters delegating to M’s getters? the best way to explain is with example so: should the vm expose the person to the data template or encapsulate the model properties with his own properties?

Unlike the Presenter in MVP, a ViewModel does not need a reference to a view. The view binds to properties on a ViewModel, which, in turn, exposes data contained in model objects and other state specific to the view.

The bindings between view and ViewModel are simple to construct because a ViewModel object is set as the DataContext of a view. If property values in the ViewModel change, those new values automatically propagate to the view via data binding.

The names of certain classes include well-known terms from the MVVM pattern, such as ending with “ViewModel” if the class is an abstraction of a view. This approach helps avoid the cognitive chaos mentioned earlier.

There is one issue with this approach though; the view model class has a dependency upon the view-related System.Windows.Input.MouseWheelEventArgs type and this kind of breaks the important MVVM principle of separation between view models and views.

The viewmodel also exposes methods, commands, and other points that help maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself.