SUE AGILE MVVM (English)

1. Pattern MVVM
In order to provide the platform SUE-Agile adequate structure and organanizzazione components
you chose to use the architectural pattern "Model View View-Model".
It consists in the separation of the aspects of the application into three components:
• Model
• View
• ViewModel
As can be deduced easily from the previous figure the Model represents the data access. This is
one or more classes that read data from the DB, or from a Web service of any kind.
The View is the view of the application, the user interface, while the ViewModel is the meeting point
between the View and the Model: the data received by the latter are processed to be presented and
passed to the View and vice versa.
The ViewModel (VM) can be thought of as an abstraction of view, but at the same time is also a
specialty of the view that the model used for data binding. The VM is particularly useful when the
Model is complex, or already exists and can not be changed, or when the data types of the model
are not easily connected to the view.
When the user interacts with the view, instantly the status change is communicated to the ViewModel
(thanks to the Data-Binding) and in response to the change of state or the activation of a method the
ViewModel "acts" by the Model and updates her status. The new state of ViewModel is then reflected
on the View.

2. It 'important that the ViewModel keep in their state not only the information retrieved through the
Model, but also the current state of the display: it allows him to be completely decoupled from View.
One way to visualize the concept is to think of the applications that make use of this pattern as a
tree composed of ViewModels, each responsible for a particular "area" of the user interface, which
realizes a whole a sort of state machine: each Once the user calls the application, and thus indirectly
the "machine", it reacts by changing its state and performing under its control the operations of the
business domain.
In this view, the view is reduced to a "glass" through which the user looks at the operation of the
"machine".
This allows for easy separation of the behavior of his "Look & Feel"; This is extremely beneficial in
development scenarios (lately more and more popular) in which aspects of User Experience are
treated by figures with precise skills, other than those necessary for the development and coding.
To facilitate this separation, the ViewModel must be designed in terms as possible abstract; for this
reason it is preferable to avoid direct dependencies View itself, or to specific components of the UI
technology. And 'quite common for modern applications make use of the so-called UI composition,
or of the ability to compose the user interface by dynamically creating several smaller parts, often
coordinates, placed in appropriate areas of a "scaffold" main called shell. A classic example
(probably among the most complex) of this technique is the UI of Visual Studio, consists of a large
number of panels, toolbars and document windows, fully customizable and extensible with new
components provided by plugins.
In addition to the purely "visual", however, the UI Composition requires the presence of some kind
of infrastructure to regulate and manage the life cycle (creation, initialization, activation, deactivation,
release) of the various portions of the screen.
The MVVM pattern does not prescribe a precise line for these aspects; the different implementations,
however, are divided into two main groups:
• View-First: the composition process is driven and urged by the View; the latter, that is,
determines which parts are to be made and in what area of the shell are shown. This setting
requires that the ViewModel associated with each part of the View is instantiated and
connected in the next stage;
• Model-First: the composition is handled primarily by instantiating the ViewModel connecting
and then the corresponding View. In this setting, which I consider more natural and in line

3. with the philosophy of MVVM, the composition takes place primarily at the level of the
ViewModel, by creating (also dynamic) of a "tree" of the various parts; View is to the left with
the task of representing this tree and its variations using the usual mechanisms of binding
and templating.
•
As mentioned in the previous paragraphs The ITS-Agile was developed in a type environment
.NET.Si it is then made use of the C # language in the part that interfaces with the data level, while
encoding the View-Model it was decided to use the script-language "Typescript", whose main
characteristics are better outlined in another section of the document. For the View were instead
exploited the potential and the innovations introduced by the mark-up language HTML5. Important
for the connection between these last two components was undoubtedly the Seller KnockoutJs that
has allowed to implement in a simple and optimal mechanisms of data-binding.
One of the biggest advantages of adopting this pattern is undoubtedly the ability to edit individual
parts of the code without affecting the other, thereby ensuring a better maintainability of the same
and greatly simplifying the testing phase.