SUE AGILE MVVM (English)
0 likes211 views
The document discusses the Model-View-ViewModel (MVVM) architectural pattern. MVVM consists of separating an application into three components: the Model (data access), the View (user interface), and the ViewModel (mediator between Model and View). The ViewModel processes data from the Model to present it to the View and passes user input from the View to the Model. This separation allows changes to one component without affecting the others, improving maintainability and testability. The document also discusses using MVVM with C# for the Model, TypeScript for ViewModels, and HTML5 for Views, connected with KnockoutJS for data binding.
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.