How MVC Works

Usually the controller instantiates the view and the model in the constructor or, in certain implementations, are injected by the main application class via dependency injection. The relation between a controller and the views could be one to many, so a controller could handle multiple views: the same relationship is valid for the models as well.

When we want to scale up this architecture for large projects usually we try to split up these relationships in order to have almost a 1 to 1 relation between these three objects so we can reuse components that are self-contained and architected in the same way the entire application works, like a Russian doll.

As described before the main aim of a model is storing the application state and everything that should be persistent across a single or multiple views, usually every time the application state changes or data are updated; the model is triggering an event in order to update the view.

In the vast majority of implementations the object listening for any state or data change is the view, but in certain implementations we can also find a total separation between the model and the view where the controller in this case is listening to the change and is propagating this information to the view.

The view is simply responsible for displaying the application data and listening for any user interactions.

Figure 2-3 shows how MVC works with an implementation of a calculator in JavaScript.

This is the final result of what we want to achieve.

It is a simple calculator where every time we are clicking a button, we add the value on the display on the top and when the user is going to click the button “=” we will display the result.

Let’s start to explore our MVC example from the controller. See Listing 2-1.

In our implementation, the controller is going to instantiate the view and the model, and it’s injecting an event emitter for communicating between objects via events. This will immediately improve the decoupling between objects because if in the future we want to reuse some of these objects in other projects, we won’t need to copy more than the object we are interested in, considering they are communicating via events, and as long as we respect the contract our code becomes reusable and flexible.

We are going to use React.js for handling the views of our project.

React usually renders the components again when there is a properties update, but in our case what we implement is using the event bus for notifying the view that a new result should be rendered on the calculator’s display, and then the view will retrieve the data from the model, updating with the new string the display.

In order to do that, we need to inject the model and the emitter instance inside the view. See Listing 2-2.

Then we will use the React Component life-cycle methods to store these two objects locally and listen for any change from the model; when a change happens, we are going to update a state property inside the React component to display the correct value. See Listing 2-3.

So, every time the displayValue property is updated, this will trigger the render function; therefore the view will be updated with a new result as shown in Listing 2-4.

Inside the model instead, we are going to keep the application state, handling what should be displayed in our view and performing some calculations.

Our model is composed by a few methods that will allow the controller to call every time a button is clicked from the Calculator keyboard as you can see in the following code in Listings 2-5 and 2-6.

The Controller, via the emitter object, is listening for any event triggered by the view and it is requesting to the model to perform some operations like reset, calculate, or add a new value.

The model, instead, every time totalOperation value is changing it, notifies via the event bus our view that will display the new value updating the state property of our React component, triggering then the render function.

MVC is a pretty simple and straightforward pattern: there is a good separation of concern, each object has a unique responsibility, and all the information is well encapsulated.

How MVP Works

The presenter object is inspired by the presentation model pattern, and my favorite implementation is when the presenter is designed as a Supervising Controller where it retrieves all the data useful for a view from the model, and at the same time it should handle any user interaction updating the model. As mentioned before, the views are passive or if you prefer dumb, they just know how the rendering logic works, possible animations, integration with CSS styles, and so on.

On top, the presenter is also dealing with updating the model and retrieving the information needed for rendering a view. Usually, in complex applications, you could have a persistent model (or more than one model maybe exposed by a façade) across the entire life cycle of an application and multiple presenters that retrieve and update the application data in the models.

Another important point to highlight is the fact that the model and the view should not be aware of each other; maintaining these two completely isolated from each other will help a lot in the case of large applications or when we need to swap views for targeting different devices.

Imagine for a moment that our assignment is a project where we need to target different devices like browsers, mobile, and smartTVs – exactly the same application but different UI for different targets considering that each target has different input methods and UI patterns.

With an MVP architecture, maintaining the behaviors inside the presenter, the business domain in the model and having just passive views for the UI will allow us to have similar behaviors across the application, reusing the same code for the models and changing the views – adapting them for the device we are targeting without much effort.

It’s time to see MVP in action with the Calculator example discussed above, but this time with the Model-View-Presenter in mind.

We can start from the App.js file where in the constructor we are going to create the model and the presenter, and we import the view called Calculator.jsx.

We then inject React component and model inside the presenter as shown in Listing 2-7.

Then we can move inside the presenter where we are going to store all the objects injected in variables and then we render the React component injected. See Listing 2-8.

In our Presentation model we are injecting the model and the view for having complete controls on them; we then call the method renderView that will be our trigger for communicating to a React component to render again because something happened inside the application and the UI should be updated.

As you can see, the view doesn’t have any knowledge of the model but we pass the result to display in our calculator via the props object exposed by React.

Now it’s time to take a look at the view; and as we defined at the beginning of this section, the view should be a passive view, so in this case it is taking care of what to render and how nothing else should be integrated in a passive view.

The communication with the presenter is happening via a method passed via the props object. Like we have seen in the renderView method, the presenter is passing a callback that should be invoked every time the user is selecting a button of our calculator. See Listing 2-9.

All the methods present in the React component are defined for rendering the correct button or the display, and this.props.onBtnClicked is the method passed by the presenter.

This method is identifying which button was selected so the presenter can capture the user interaction and it calls the correct method exposed inside the main model as you can see in the snippet below in Listing 2-10.

It’s time to see what the model is doing; in this case the model is taking care of all the calculations and maintaining the application state. That will facilitate the debugging of our application because we know that the view is dealing merely with the UI of our application, and the presenter is handling the user interactions and the model keeps the application state and the caching of application data.

Let’s take a look to the model shown in Listing 2-11.

As you can see in the model, there are all the methods called by the presenter, like reset or calculate, and a few others like checkSymbol and getValue, used for handling the application logic.

The separation of concerns in MVP is very strong and any application would be easier to debug and maintain if we properly apply these few concepts; it’s definitely an architecture that largely improved the MVC concept created 10 years before it.

How MVVM Works

The first difference is that we have a View-Model instead of a presenter; this specific object will be the bridge between the data stored inside a model and the view.

In a nutshell the view-model is responsible for exposing the data present inside the model to the view and it is also responsible for preparing the data in a way that the view expects, so you can immediately understand that the logic of the view-model is tightly coupled with what the view should render.

For instance, let’s imagine that we have a stock value stored in the model with dollars currency but the view needs it to be shown in euro. In MVVM the model stores the raw data, that is, dollars value, and the view-model would be responsible for converting the value to a given currency, in this case euro.

Another important aspect of the View-Model is the fact that it has a relationship with the views that is 1 to many: therefore we can have one view-model that is handling multiple views or components.

The communication of the View-Model and the view usually happen via bindings; therefore every time a value is updated on the view or in the View-Model, this value is communicated to the other object in order to keep it in sync.

It’s very important to understand that with MVP we enforced the concept of complete separation between the model and the view and in MVVM this strong concept doesn’t change at all.

The model is very simplistic; we store data in a raw format without any particular change, and in this case we should even avoid keeping the state in the model and moving this information to the view-model or even the view if it’s a small component.

Let’s see now how our calculator would work with an MVVM architecture.

The App.js file is instantiating all the objects for an MVVM architecture: model, view-model, and view; in the view-model constructor we are going to inject the model and view instances so it will be able to retrieve data from the model and serve the view with the correct value to display. See Listing 2-12.

The Calculator view is a React component that has two key concepts: dispatching the data from the view to the view-model and retrieving the data from the view-model.

In order to do that we can use a data binding library or simply events as both are accepted from MVVM architecture, therefore we are using an event emitter, injected when the view and the view-model were instantiated, for handling the communication between these two objects, as shown in Listing 2-13.

In manageDisplayState we have all the events we will communicate to the view-model, but in the componentWillMount we define only the event we need to listen for updating the calculator’s display.

The rest of the view is very similar to the other views we have discussed in the previous examples.

Now it’s the turn of our view-model. Here we need to do exactly the opposite of how we handled the events in the view; therefore we are going to listen for all the events emitted by the view and dispatch the event for updating the view’s display every time the value changes. See Listing 2-14.

The view-model is responsible for retrieving and updating the data stored in the model, so every time the user clicks a button in our view we are going to update the value in the model and then call the updateDisplayAndState method for dispatching this change to the view.

We keep a state internal to the view-model to understand which method we need to call during the calculation; therefore we need to update it when the state is changed.

Let’s see, for instance, how we handle the changes in the three methods we have created for handling these operations, as shown in Listing 2-15.

It’s now clear that the majority of application business logic is present in the view-model; therefore if we want to reuse a specific component or part of the application. we need to maintain the event or the binding contract between the view and the view-model as it is. So we can say that these two objects become slightly more tightly coupled compared to their relation in the MVP architecture.

Last but not least, it’s time to discuss the model. As you can see, the model just exposes a few methods in order to update the value to display; it doesn’t have any data manipulation or any state, and in this case the model is just a data representation of the main application so if we need to use it in combination with another view-model, the model will provide the data expected and nothing more. See Listing 2-16.

How Angular Works

The architecture we will evaluate in this section is related to Angular 2 and onward (Figure 2-6), so we won’t take into consideration the previous one because it works in a different manner.

We will now go more in depth of this architecture, analyzing the different parts that compose an Angular project.

Any Angular application has at least an NgModule called the root module ; an NgModule is not like a normal JavaScript Module. The peculiarity of the NgModule is the metadata; in each NgModule (root module included), we will describe how the module is composed, and in particular we will define which components belong to a module, if a module has dependencies from other modules, directives, or components; and we also describe the services used by the components present in the module.

As described before, any Angular application contains at least one module called the root module.

For instance, this is the root module created for our Calculator project in Angular:

As you can see in this code snippet, Angular is largely made up of decorators (@NgModule) for wrapping our code inside the Angular framework.

The next topic to introduce is the Angular components. Since Angular 2 we have the possibility to create components, and we can think of them like a bridge between the template system present in Angular and the data we can retrieve from REST API or specific endpoints. Their role is mainly retrieving the data and populating the template with new data via a binding system that is present out of the box in Angular 2.

In order to define a component in Angular we need to specify another decorator, @Component. For our calculator example, we have defined just one component considering how simple the application is; but potentially we could have split them in multiple parts as shown in Listing 2-17.

As you can see in the decorator (@Component) we are specifying the HTML template and the CSS associated with the component. The objects to inject will be accessible inside the component but they will be instantiated by Angular and a selector that is just an ID to identify the component.

The last thing to mention about Angular components is that we can use life-cycle hooks like ngOnInit method that is triggered when the component is initialized and in our case we use it to set the first value in our calculator display.

Now it’s time to see how the components interact with templates. Angular has its own way to handle HTML markup; we can use some directives in order to iterate through a data structure for displaying multiple HTML elements or for adding specific attributes if a certain condition happens in our code.

In our example we have associated an app.component.html template to the app.component.ts described above and this is the code used for the template:

In this code it is important to highlight a few concepts. The first concept is that the binding with the total property is created inside the component, so every time we are updating this value, the new value will automatically be displayed inside our template.

The other interesting thing is how we have created the buttons in our calculator; we are iterating an array present in the component object and with *ngFor directive we are creating multiple tags with different values; then, when a user clicks on the button we are calling the method updateTotal passing the button’s label; also in this case we use Angular markup for triggering the user interaction ((click)="updateTotal(value)").

Interestingly enough, just with few lines of code. Angular provides a simple but very powerful mechanism of data binding, templating, and styling our views.

It’s time to talk about the dependency injection part; as we saw in the component decorator we are defining an array of providers. Basically we are injecting UpdateTotalService and CalculatorModel to the component.

The CalculatorModel won’t be used by the component but if we want to inject this object inside the service, we need to specify it there.

What is a Service in Angular? A Service is inspired to the Command Pattern , and it’s used for fetching data from an endpoint or for retrieving/passing data to a model like in our case.

This is our UpdateTotalService class as shown in Listing 2-18.

This service exposes a few methods that will be used for manipulating the model in a specific way.

The model is injected in the constructor via the framework; therefore when we call this.updateTotalService.reset(); from the component class we won’t need to have any knowledge of the model but the service will return the value retrieved from the model, isolating the view from the model like we have seen in the MVVM pattern, for instance.

Another important thing to notice in this class is the injectable decorator provided by Angular for describing a class that is injected inside a component; just adding this decorator, the framework knows when to instantiate and inject.

The last part to describe is our model that is a very basic model with some knowledge on how to manipulate the data to store. Here again we are using the @injectable decorator for the possibility of being injected by Angular. See Listing 2-19.

Our model is a simple object that contains the source of truth for our application, maintaining the state and the value that should be displayed inside the views.

Just to summarize the Angular calculator example: we have seen the key concepts of Angular, we also noticed quite a few similarities with MVVM and MVP architectures like the relation between view and template or who is handling the user interactions. The last thing worth mentioning is that Angular can become a reactive architecture pretty easily, because it incorporates Rx.js library inside the framework; therefore, within a certain degree, we can twist this architecture to a Reactive one almost out of the box.

How Ember Works

Ember architecture (Figure 2-7) is based upon MVVM architecture, and there are some key elements that composed this framework:

• Routes

• Templates

• Components

• Controllers

• Models

In Ember everything starts from a route module and each view is tightly coupled with the endpoint associated. By default any Ember application has a main route system where we define all the application routes; for instance, in our calculator application we have defined this route shown in Listing 2-20.

That means the root of our web application will be routed to the calculator route. Because Ember works with conventions, we need to save the modules in the right folders in order to be picked up. But luckily the Ember CLI comes to the rescue by providing some useful commands that prepare all the files needed out of the box:

And automatically the CLI will generate a route file, the associated test file, and the template, and then it will also insert the code for the new route to the application route system.

The route we created for our calculator exposes the model to the template; in Ember only the routes and the controllers have access to the model. Therefore, there is a strong separation of concerns between the view and how the model should be in an MVVM architecture .

The concept of Model in Ember is slightly different from what we are used to; the Model class defines that the value will be present in the store (the concrete model) facilitating the data validation when they hit the client side of our Ember application.

If we check our model class, present inside the models folder, we can see that we are defining two properties” both of type string, one called total and the other state. See Listing 2-21.

As you can see from the route code above, the store is a data structure centralized for the entire application (think of it as a Singleton), accessible by the routes and controllers, so independently from the amount of templates, routers, or controllers our application is composed of, we have a unique source of truth to fetch or cache data.

The store object is a very interesting one because it allows data to be automated and fetched from an endpoint, and then it will store the response directly inside the store object without handling all the code for defining these kinds of operations.

The store works with records; a record is a concrete model that contains the data fetched from a REST endpoint or cached inside the application like in our case.

It’s very important to notice the structure of an object stored in a record, as shown in Listing 2-22.

Inside the store we need to define the data object with a unique ID; a type value, used for retrieving it later on; and the attributes we need to store inside it, for our application will be the value total and the application state.

Because we are not fetching the data from any remote endpoint we are using peek Record method, which will skip the server request and retrieve the data directly from the concrete model.

Instead if we would need to retrieve data from a specific REST endpoint, we could use find Record that will perform a request to the endpoint specified, and it will store the response inside the store object.

Our application logic sits in the controller where we are providing public methods for the views to be called and we are handling the setting and getting of data to and from the model.

When we extend the base controller from the Ember framework we have an object called actions where we can expose all the methods to the template; in our case we just have one method called updateTotal :

Here in each case we are retrieving the current value from the store and manipulating it, but the annoying part is that Ember works a lot with strings in order to identify a specific object or value. Therefore we won’t have code completion provided by our editor and it could be prone to error if it’s not properly wrapped in a constant statement.

The last bit to discuss is the template. Ember is using handlebars out of the box; therefore if we are familiar with this famous template library we will be productive in no time.

Handlebars has some specific markup, like Angular, for identifying specific behaviors like filtering, creating similar tags populated with data retrieved from the controller or the route and so on.

This is the handlebars code needed in order to render our calculator:

It’s interesting to highlight how we handle the method exposed by the controller via the action command:

We identify the method name passing a parameter called value in this case, and specifying when the method should be invoked: in this case on mouse down.

To summarize, Ember is a really productive framework based on MVVM architecture with a lot of common activities ready to be used out of the box. It favors convention over configuration, it has a reach ecosystem composed by different tools and libraries, and the documentation is really exhaustive.

How Redux Works

The starting point of any Redux project (Figure 2-8) is usually a main application where we create the store object and we wrap our main view inside a provider object from the Redux library. See Listing 2-23.

export default class App{

    constructor(){

        const store = createStore(CalculatorReducer);

        const cont = document.getElementById("app");

        ReactDOM.render(

            <Provider store={store}>

                <CalculatorContainer/>

            </Provider>, cont);

    }

}

let app = new App();

Listing 2-23

App.js

As we mentioned before, after creating the store and associating it to a specific reducer (Calculator Reducer), we are wrapping our main view (Calculator Container) inside a Provider object from the redux library.

Think about the Provider as an object that receives as input the store and it propagates it to all the container components inside an application in order to have complete access to it.

Considering we have mentioned the container components, it’s time to move to the view part, where we need to distinguish between presentational components and container components.

The creator of Redux, Dan Abramov, wrote a post on Medium.com regarding this topic where is explaining the difference between the two types of components.

To summarize Dan’s thoughts, in Redux we distinguish the presentational components as component with the only scope of managing the look and feel of the view, more or less like the Passive View described in this chapter. Meanwhile we identify the container components as the ones that can handle the presentational component logic like user interactions, having access to the store, and mapping the store values to the React component via a props object, similar to the Supervising controller of the MVP architecture.

This approach will lead to a better separation of concern and reusability of our components across different projects.

Based on what we have just described, it’s time to see what a presentational component looks like and how we handle the communication with the Redux framework.

In the calculator example, our presentational component code looks like that shown in Listing 2-24.

We can immediately spot that we are focusing more on what our component looks like than what it does. The only method that is going to be used is the onButtonClicked method retrieved from the props object as well as the result property that will be used to show the calculation inside the calculator display div element.

The entire logic of this component as well as the communication with the rest of the application is made inside the container component, as shown in Listing 2-25.

Before we move to the reducer, it’s good to understand what an action is. Basically an action is just a plain JavaScript object. Inspecting the CalculatorAction module, we can see it clearly in Listing 2-26.

The actions are similar to commands where they bring with them the information needed to the reducers in order to change the current state to a new one. Usually they have a property type where we define the type of action called from the store.dispatch method.

Finally, it is the turn of the reducer. The reducers are used when we need to change the application state, because the action is notifying us that something happened inside the application but it doesn’t have the knowledge of how the application should change – that’s the reducer’s duty. See Listing 2-27.

In our reducer, we set as the default state the reset action that starts the application with the initial state (INIT in our switch statement).

Every time an action is dispatched, the store calls the reducer passing the current state and the action dispatched, and then the reducer is mapping the action to the next application state.

Redux is a very simple but effective state management library, and it’s interesting that there are many similarities with the MVP architecture – in particular for the relation view presenter like we have in Redux with the presentational component and its container.

Also in the redux ecosystem there are other libraries that we can use in combination with Rx.js, for instance, or other reactive libraries.