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.
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.