One of the biggest issues with the Backbone documentation is not to have a clue about how to use its objects. You, as developers, should figure out the responsibilities for each object across the application; if you have some experience working with Backbone, then you would know how difficult it would be to build a Backbone application.
In this section, I will describe the best uses of the Backbone objects. Starting at this point, you will have a clearer idea about the scope of responsibilities in Backbone and this will lead the design of our application architecture. Keep in mind that Backbone is a library with only the foundation objects; therefore, you will need to bring your own objects and structure to make scalable, testable, and robust Backbone applications.
The only responsibilities of views are to handle the Document Object Model (DOM) and listen for low-level events (jQuery/DOM events), and transform them into domain ones. The Backbone Views works closely with template engines in order to create markups that represent the information that is contained in models and collections.
Views abstract the user interactions, transforming their actions into business value data structures for the application. For example, when a click event is triggered from a Save button in the DOM, the view should transform the event into something similar to a save:contact event using Backbone Events with the data written in the form. Then, a domain-specific object can apply some business logic to the data and show a result.
It is a rule that business logic on views should be avoided; however, basic form validations such as accept only numbers are allowed. Complex validations should still be done on the model or the controller.
Backbone Models are like database gateways in the server side, their main use is to fetch and save data to and from a RESTful server and then provide an API to the rest of the application in order to handle the information. They can run general-purpose business logic, such as validation and data transformation, handle other server connections, and upload an image for a model.
The models do not know anything about views; however, they can implement functionality that is useful for views. For example, you can have a view that shows the total of an invoice and the invoice model can implement a method that does the calculation, leaving the view without knowledge of the computation.
You can think of Backbone Collections as a container of a set of Backbone Models, for example, a Collection of Contacts models. With a model, you can only fetch a single document at time; however, Collections allow us to fetch lists of Models.
A big difference from Models is that Collections should be used as read-only, they fetch the data but they should not write in the server; also it is not usual to see business logic here.
Another use for Collection is to abstract RESTful APIs responses as each server has different ways to deal with a list of resources. For instance, while some servers accept a skip parameter for pagination, others have a page parameter for the same purpose. Another case is on responses, a server can respond with a plain array, while others prefer to send an object with a data, list, or other key, where the array of objects is placed. There is no standard way. Collections can deal with these issues, making server requests transparent for the rest of the application.
Routers have a simple responsibility: listening for URL changes in the browser and transforming them into a call to a handler. A router knows which handler to call for a given URL. Also, they have to decode URL parameters and pass them to the handlers. The infrastructure application bootstraps the application; however, routers decide which subapplication will be executed. In this way, routers are a kind of entry point.