MVVM Introduction - MVVM

What is MVVM Introduction?

The well-ordered and perhaps the most reusable way to prepare your code is to use the 'MVVM' pattern. The version, Model, ViewModel (MVVM pattern) is all about guiding you in a way to arrange and structure your code to write maintainable, testable and extensible applications.

Model − It simply holds the information and has nothing to do with any of the business logic.

ViewModel − It acts as the link/connection among the version and view and makes stuff look pretty.

View − It really holds the formatted information and essentially delegates everything to the model.

Separated Presentation

To avoid the issues because of putting application logic in code-behind or XAML, it is great to use a method called separated presentation. we're trying to avoid this, where we can have XAML and code-behind with the minimum required for working with person interface items directly. person interface lessons also include code for complex interaction behaviors, application logic, and everything else as proven inside the following figure on the left side.

• With separated presentation, the user interface class is much easier. It has the XAML of course, however the code in the back of does as low as is practical.
• The utility logic belongs in a separate class, that is often called the model.
• However, this is not the whole story. in case you stop here, you are likely to copy a completely common mistake in order to lead you down the path of records binding insanity.
• A lot of developers try to use information binding to connect elements inside the XAML directly to properties inside the version.
• Now sometimes this can be okay, however often it is not. The trouble is the version is entirely involved with matters of what the application does, and not with how the user interacts with the application.
• The manner in which you gift information is often somewhat unique from how it's based internally.
• Moreover, most user interfaces have some state that does not belong in the application version.
• for example, in case your user interface uses a drag and drop, some thing desires to preserve track of things like where the object being dragged is right now, how its appearance must exchange because it actions over possible drop objectives, and the way those drop targets may also change as the item is dragged over them.
• This type of state can get surprisingly complex, and needs to be very well tested.
• In practice, you usually need a few different class sitting among the person interface and the version. This has essential roles.
  • First, it adapts your utility model for a selected user interface view.
  • Second, it is where any nontrivial interaction logic lives, and by using that, I suggest code required to get your user interface to behave in the way you want.