It is possible to develop Backbone applications only using the Backbone objects that are described in the previous section; however, for a medium-to-large application, it's not sufficient. We need to introduce a new kind of object with delimited responsibilities that use and coordinate Backbone foundation objects.
This object is the public interface of the subapplications. Any interaction with the subapplications should be done through its methods. The calls made directly to internal objects of the subapplication are discouraged. Typically, methods on this controller are called from the router; however, they can be called from anywhere.
The main responsibility of this object is to simplify subapplication internals. Its main work is to fetch data from the server through models or collections and, if an error occurs during the process, it is responsible to show an error message to the user. Once the data is loaded in a model or collection, it creates a subapplication controller that knows the views which should be rendered and have the handlers deal with its events.
A controller acts like an air traffic controller for views, models, and collections. When given a Backbone data object, it will instantiate and render the appropriate views and then coordinate them. On complex layouts, it is not an easy task to coordinate the views with the models and collections.
The Business logic for the use cases should be implemented here. The subapplication controller implements a mediator pattern, allowing other basic objects such as views and models keep it simple and loose coupling.
Due to loose coupling reasons, a view should not directly call to methods or events of other views Instead of this, a view triggers events and the controller handles the event and orchestrates the views behavior if necessary. Note how views are isolated, handling just its owned portion of DOM and triggering events when required to communicate something.