Tuesday 30 August 2016

The MVC and MVVM Software Architectural Patterns

The MVC and MVVM  Software Architectural Patterns

MVC (Model, View, Controller)


The MVC pattern dates back to the 1980s and early graphical UIs. The goal of MVC is to factor the code into three separate responsibilities, shown in Figure 7. Here’s what they do:
  • The model represents the domain data and business logic.
  • The view displays the model.
  • The controller receives user input and updates the model.
The MVC Pattern
Figure 7 The MVC Pattern



MVVM (Model, View, ViewModel)
A more recent variant of MVC is the MVVM pattern (see Figure 8). In MVVM:
Commonly called Model-View-Binder in non .net platfoms

  • The model still represents the domain data.
  • The view model is an abstract representation of the view.,
    the view model is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented
  • The view displays the view model and sends user input to the view model.
The MVVM Pattern
Figure 8 The MVVM Pattern
In a JavaScript MVVM framework, the view is markup and the view model is code.
MVC has many variants, and the literature on MVC is often confusing and contradictory. Perhaps that’s not surprising for a design pattern that started with Smalltalk-76 and is still being used in modern Web apps. So even though it’s good to know the theory, the main thing is to understand the particular MVC framework you’re using.

Thursday 11 August 2016

Single Page Applications Fundamentals

https://msdn.microsoft.com/en-us/magazine/dn463786.aspx

What is a Single Page App.


Single-Page Applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app
SPAs use AJAX and HTML5 to create fluid and responsive Web apps, without constant page reloads. However, this means much of the work happens on the client side, in JavaScript.


Traditional Page Lifecycle Vs SPA Lifecycle


In a traditional Web app, every time the app calls the server, the server renders a new HTML page. This triggers a page refresh in the browser. If you’ve ever written a Web Forms application or PHP application, this page life-cycle should look familiar.

In an SPA, after the first page loads, all interaction with the server happens through AJAX calls. These AJAX calls return data—not markup—usually in JSON format. The app uses the JSON data to update the page dynamically, without reloading the page.  When the json is retrieved the app uses a data-binding JS frame work like angular or knockout to bind the json result to the HTML.























One benefit of SPAs is obvious: Applications are more fluid and responsive, without the jarring effect of reloading and re-rendering the page. Another benefit might be less obvious and it concerns how you architect a Web app. Sending the app data as JSON creates a separation between the presentation (HTML markup) and application logic (AJAX requests plus JSON responses).

This separation makes it easier to design and evolve each layer. In a well-architected SPA, you can change the HTML markup without touching the code that implements the application logic (at least, that’s the ideal). You’ll see this in action when I discuss data binding later.

In a pure SPA, all UI interaction occurs on the client side, through JavaScript and CSS. After the initial page load, the server acts purely as a service layer. The client just needs to know what HTTP requests to send. It doesn’t care how the server implements things on the back end.

With this architecture, the client and the service are independent. You could replace the entire back end that runs the service, and as long as you don’t change the API, you won’t break the client. The reverse is also true—you can replace the entire client app without changing the service layer. For example, you might write a native mobile client that consumes the service.



JS Data-binding Frameworks.