Model-View-Controller (MVC): The Basics
Model-View-Controller (MVC): The Basics
Take a closer look at the the Model-View-Controller (MVC) pattern of web application architecture.
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
The Model-View-Controller (MVC) pattern is a web application architectural pattern that focuses on one thing – separation of concerns. The goal is to separate data handling from display logic, and separate the presentation of the data from its underlying representation and tied-in application logic. MVC is a very common and very popular architectural structure for website design and development. Below we’ll dive deeper into the MVC pattern. We’ll explore each of the components, their intended use, and how they are typically used in a web application. Finally, we’ll tie it all back into AngularJS, and see how we can use the MVC pattern to greatly ease application development.
The model layer is the lowest level of the back end of your application. It sits on top of the data store and handles manipulating the data at a database level. Furthermore, current design idioms implement most of you application’s logic at the model layer, meaning that not only do models manage their own attributes, they are also responsible for handling all side-effects in your application’s back end when a change occurs. If you’re going to send an email when a user logs in, that type of code is typically implemented in the model.
The above approach is known as a Fat Model/Skinny Controller approach, and is the primary style used by most major MVC frameworks (such as Rails and Django). There are other approaches that move application logic out of the Model and into the Controller, but that simply repositions the complexity. One of the issues that is faced with the Fat Model pattern is that it avoids the separation of concerns that is inherent in good object-oriented programming practices. To get around this, many developers use auxiliary directors and repositories that handle the marshaling and the business logic related to object updates, allowing models to focus on simply updating the data store as necessary.
Controllers are the glue that tie an MVC application together. At their most basic level, they handle three tasks: data marshaling, routing, and model updating. Data marshaling consists of communicating with the model layer and obtaining all of the objects necessary to present a particular view to the user. Routing, on the other hand, handles control flow for the application, directing the next view to be rendered by a page flow, or guiding the view layer in its data presentation as the user moves through – and interacts with – your application.
The model update portion of the controller’s responsibilities drives the persistence of data in your web application. The controller serves as an intermediary between input pulled in from the view layer, and the underlying data representation and business logic in your model layer. Much as the controller is responsible for providing all of the data needed to render the view, it also handles saving the changes from user input into the model layer. From this perspective, the controller layer is a translator that takes user input and converts it into database entries, and vice-verse.
Tying it Back to Angular
AngularJS has been called both an MVC and an MVVM framework, which can prove confusing when trying to nail down a target implementation architecture. The truth is that AngularJS has elements of both. The basic architecture is implemented as an MVC pattern, with the controller driving the rendering of HTML based upon replacing data attributes in the page’s markup with the underlying model data.
However, with AngularJS’s two-way data binding it allows for implementation of an MVVM pattern. In a traditional MVC approach, modifications at the view layer need to be sent through a controller in order to update the underlying model. MVVM, on the other hand, lets updates to the view layer drive changes to the underlying model directly. AngularJS implements this through two-way data binding.
So the reality is that while two-way data binding enables AngularJS as a driver for a MVVM application, it can be – and often is – implemented using a MVC pattern to drive data interactions. The choice comes down to how deep your application’s integration with AngularJS is – you can choose to use an MVC pattern and drive data updates as a result of a call from the view layer, or you can choose to take advantage of two-way data binding and implement an MVVM architecture.
The MVC pattern is a pattern that was originally designed for desktop applications, but has since been co-opted by the web development world. Its core design principles are driven by the desire to maintain separation of concerns in a web application, splitting out the data layer and the view layer and separating them with a controller layer that drives the application flow. By focusing on implementing your application in an MVC pattern, you can greatly ease the development process by maintaining separation of responsibility, developing an application that is truly robust and maintainable.
Published at DZone with permission of Itay Herskovits , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.