Recently I began to study the MVVM pattern and a dozen questions arose. One of them - why do we need a ViewModel? (Binding can be built in the model) Please provide examples or skip links to articles.

  • one
    If you only have a WPF model - yes, you can make it immediately a view model. Otherwise, extra properties appear in it, which should not be saved to the database, should not be implemented on the server at all, and so on. - Monk
  • four
    Because it is necessary to separate the logic of the subject area from the application logic and UI. The first is engaged in the model, the second VM. This time. Secondly, the model does not necessarily run in the UI stream and exposes the INPC. She generally can not expose the data. - VladD September
  • one
    Here's a link for you: stackoverflow.com/q/379255/10105 - VladD

1 answer 1

Formally speaking, the ViewModel is another layer of abstraction from the implementation of the UI. Next, a lot of letters.

Its meaning is approximately as follows. In the standard MVC paradigm, the question was open - how to correctly “encode” the logic of user interaction in the part that is associated with user actions, and not with some kind of business logic. A typical example is to hide / show a group of fields when clicking a radio loaf, or, for example, to validate the entered data when switching to another tab within one tab control. Another example would be the display of a dialog box asking for confirmation of an action when, for example, a certain element is changed.

Those. these are actions that, on the one hand, can have quite complex logic under them, and on the other hand, generally speaking, they have a rather distant relationship to the “model” —the entity that cementing the whole system, “cast in metal” and stored in the database. And from the point of view of architecture, adding to the model class a dozen Boolean fields of IsCheckboxSelected solely for immediate display needs is somewhat non-kosher.

Until relatively recently, mice cried, pricked, but continued to eat cactus: it was all smeared between the controller and view, additional classes and layers with repositories were written, and architectural “beauty” of the solution was sacrificed to functional requirements.

But technical progress, as is well known, is inexorable, interfaces have become more and more difficult, asynchrony, usability and all that stuff have become dominant. On the other hand, automated testing and unit testing started a triumphal march across the planet, and the question of how to test views in which the logic of user interaction is nailed to the physical "rendering" more and more sharply.

Those. on the one hand, I want to be able to write (and isolate automatically to test, which is also important) the logic of the UI, and on the other hand, I really do not want to be bound to specific labels, tags, controls, etc. etc.

The MVVM paradigm was developed to resolve this contradiction. An additional layer was introduced into the architecture - the one that is responsible for user interaction, but it is built in such a way that, ideally, it doesn’t matter whether it is displayed in a WPF application under Windows, a text console a la DOS or a knock. tomtam This is achieved due to the fact that the MVVM classes themselves are built on the basis of ordinary POCO objects, logic is the methods of these objects operating with data in the fields of objects + event handlers (UI is, in fact, an asynchronous thing). And the physical mapping of these very objects to the user interface — these are already binders, templates, converters, and other buns of a specific implementation — work as derivatives from our twist model (that is, attach to it).

Pros - such classes are relatively easy (or at least just possible) to test with unit tests, the overall architecture is more streamlined, larger applications are faster to develop and easier to maintain. Cons - additional overhead on the view model and the need for developed means of binding.

Something like this.