by Samuel M. Breed, author of Backbone.js in Action
This article explores the concepts that Backbone uses to build a foundation for applications. In order to really know a person or a discipline or library, you first must know where it came from.
Patterns for client-side applications
If you are familiar with an object-oriented programming language, you have likely come across the term Model-View-Controller (MVC) before. The MVC pattern is often found in server-side frameworks like Ruby on Rails or Django, where its used to negotiate the storage, presentation and management of data in a way that's well-isolated and testable. As we'll see in the upcoming pages, Backbone borrows heavily from MVC and it's derivative patterns—but what emerges is something a bit different—the same metaphors are used, but they take on a different meaning when applied in the browser. These patterns are colloquially know as MV* when applied to front-end applications. But before we can dig into that ever-so-important asterisk, we need to talk about MVC and why it even matters in the first place.
In the simplest terms, MVC is used on the server to organize and separate concerns. By keeping Models, Controllers, and Views as distinct interfaces, its easier to add features or making changes to an application over time. The alternative is to create what are known as monolithic applications; apps that have all of their logic for display, persistence and presentation all in one place. As illustrated in figure 1, MVC provides a template for structuring the different concerns of an application: Models represent the domain specific knowledge and data in the application, and are capable of notifying observers of state changes (changes to the underlying data they represent); Views typically represent the UI layer, displaying model data and listening to changes in the model's state; Controllers handle user input and relay any changes that need to happen on the model layer.
Figure 1 A traditional Model-View-Controller relationship
The main problem addressed by MVC is the tendency for monolithic applications to be prone to difficult-to-solve bugs that result from complex logic or tightly coupled classes. Tight coupling is a byproduct of most procedural scripting languages and happens when a single class is dependent on the inner workings or implementation details of another, possibly unrelated class. For instance, the act of making database calls directly from a presentational template is an example of tight coupling; the template is responsible for both outputting an HTML template and communicating with a database or ORM to retrieve the data its presenting. When these monolithic architectures are left unchecked, it becomes difficult to test or isolate different areas of functionality. Structured and maintainable code is important to developer productivity, and helps developers craft software more effectively. MVC patterns address this problem by applying to divide the responsibilities in your application.
There are a host of similar patterns with similarly named acronyms, the most important and most relevant to Backbone is the Model-View-Presenter pattern (MVP). MVP is a derivative of MVC, but shifts all of the middleman functionality to a Presenter, rather than wiring views and controllers directly to the model. Model-View-Presenter (figure 2) is the closest approximation to the relationships that exists between Backbone Core classes, your server and the DOM.
Figure 2 The Model-View-Presenter pattern
But try to not get hung up on the semantics of MVP vs. MVC vs. MV*—the takeaway is that separating the areas of functionality in your application is the simplest way to avoid monolithic architectures that are hard to grow, scale and change over time. The assumptions you have about your software projects on day 1 tend to be way different on day 30 or day 60, so being flexible is a key trait of a successful developer or piece of software.
MV*, a pattern for real-world applications
Figure 3 MV* in Backbone
Backbone doesn't quite fit MVC, nor does it line up exactly with the MVP pattern; the term that's been coined to describe Backbone (and similarly minded frameworks) is, fittingly, MV*. The asterisk denotes that there's some grey area around what the controller/presenter is responsible for since it's largely up to the interpretation of the developer using Backbone in their app.
Here are some other Manning titles you might be interested in:
Ext JS in Action, Second EditionJesus Garcia and Jacob K. Andresen