There Are No Controllers In Backbone
There simply aren’t. In spite of the documentation saying that routers or view may be sort of maybe almost kind of close to some of what a controller might do, there are no controllers. It’s not a construct that exists in the backbone namespace, and there’s no implementation that represents what a controller does, architecturally.
A router is not a controller. It’s a router. A view is not a controller. It’s a view. Yes, both routers and controllers share some of what a traditional MVC framework would call a controller. No, neither of these is a controller.
More MVP Than MVC
I’ve spent 5 years building MV* family applications in thick-client / GUI systems (Windows / WinForms / WinMobile) and on the web (Rails, ASP.NET, ASP.NET MVC, etc). Backbone clearly fits in to this family, but it’s also clearly not MVC. My opinion says that it’s closer to MVP, where the backbone view is closer to a P (presenter) and the HTML/DOM is the V (view).
Consider this picture of an MVC process flow (from Wikipedia):
Here, the models contain data which is used to populate views. Actions that a user initiates are handled by the controller which processes the request and updates the models. The models are then fed back to the views and the cycle starts over. It’s cyclical in nature.
And now consider this picture of an MVP process flow (from LessThanDot.com):
Notice the difference? Right – it’s not circular. That’s the big difference between MVC and plain-jane MVP (a.k.a. “passive view“). MVP does not work in a circular fashion the way MVC does. Instead, it relies on a presenter (the “P” in MVP) to be the coordinating brains of the operation. The presenter in an MVP app is responsible for taking the data from the models and stuffing it in to the views. Then when an action is taken on the view, the presenter intercepts it and coordinates the work with the other services, resulting in changes to models. The presenter then takes those model changes and pushes them back out to the view, and the elevator of moving data up and down the architectural stack begins again.
Does the idea and responsibility of a presenter sound familiar when thinking about Backbone? It should… it fits almost concept for concept with Backbone’s views, in my mind. But that doesn’t mean Backbone is an MVP implementation, either. It only means that views should be thought of as presenters, not controllers.
A great reminder on why backbone.js is not a MVC (nor MVVM, MVP) framework. If anything, it's best described as a MOVE framework. Models that represent the data or nouns of your application. Operations that represent the verbs of your operations. Views that combine the nouns and verbs and present them to the the user. Finally, there are events that bind all the other pieces together and allows for a common communication channel between them.