AngularJS Basics Part 1: the Model-View-Controller approach
Leave a reply
You may have heard of the Model-View-Controller paradigm from previous programming experience in other languages.
It’s a way to organize and think about your programs that is designed to make programs easier to develop and maintain over time, especially as application complexity grows.
The MVC model is an example of what computer scientists and developers call a design pattern. It’s not a concept specific to Angular, but rather an approach to program architecture which has been implemented successfully across a variety of programming languages and environments, and which has been found to yield some good practical efficiencies as a time-tested design.
The team that created Angular has baked this concept into Angular’s in many ways and therefore – it makes a lot of sense to go with the rather sensible flow. Let’s take a look at this awesome pic which lays it all out:
This diagram represents the way most event-driven programming is modeled these days. It represents how modern web applications are architected, as well as how typical iOS (iPhone/iPad) and Android applications are built, and how many desktop applications are built as well. As far as web development goes, it represents a break from the jQuery-style of development which intimately ties business logic into the view (typically by tying it into the browser’s Document Object Model).
In MVC, the controller is the chunk of code the coordinates between the model and the various views. The model is the combination of core business logic code and persistent data (data stored in a database, or through some other kind of persistence mechanism for long-term data storage) that make up the “things” represented in the system. The model would thus contain users, user data, and active media assets such as editable files or information — for most web sites, this boils down to the long term data associated with a user account.
The model is responsible for maintaining the integrity of its own data. On a smaller web site, it could consist of tables in a single database. On a larger site, it could consist of many databases, a full API (application programming interface) and a bunch of back-end code written by some Java gurus behind the scenes.
Switching to the other extreme, the view is the part of the application which the user sees and interfaces with. It’s temporary, it’s a facade and while it gives the user a way to interact with the interesting data in the model, it’s really just the superficial, friendly front end to that hard information. Most modern internet applications actually consist of a number of views — these could consist of big web interfaces for desktops, smaller web interfaces for mobile devices, or even dedicated mobile apps. All of these views need to communicate with the back end model.
The controller is the code that mediates between the various views and the model. The controller will be a piece of code that typically runs on the end device itself, although it is also possible for it to be a piece of middleware code sitting on a front end web server (this was generally the case with traditional web applications written in languages like PHP). Nowadays, due to speed considerations and the increasing power of Javascript frameworks like AngularJS and Backbone, the controller code is much more likely to reside on the end device, servicing the view just behind the scenes, and sending messages back and forth to the model.
Splitting up applications cleanly into Model-View-Controller architecture allows developers to enjoy what is called the “separation of concerns” — that is, 1) splitting the device-specific visuals and user interactions into various views (so the CSS and light display-oriented Javascript goes here), 2) splitting the user-interface logic and model-communication logic into various controllers (for web apps, this is heavier Javascript that handles basic data integrity and manages more complex aspects of the view’s current state) and 3) splitting the heavy-duty business logic and hard data into the model. This separation of concerns lets big teams focus on specific aspects of appliation development, and makes it easier to create scalable web apps where different parts of the system can be handled by specialists.
Next post I’ll cover the basics of how AngularJS lets us do MVC. We’ll start with some simple applications where the entire MVC architecture resides inside the app itself. In more advanced lessons, we’ll start to look at how to break out the model into external systems (such as through a REST api) so that we can develop full professional-grade systems.
