0
votes

While creating Backbone Models and Collections for a web page, I feel the data can be segregated as models and collections in multiple ways.

Consider an example where I have a web page and ideally I should create one backbone view and there by one backbone model for that view. However, the data has to go in to two different data base tables at server side. In these kind of situations, I get confused whether I should just consider the front end scenario while defining view/models or should I just create them based up on the server side POJO classes structure.

I mean, If I just think from front end perspective, I just need to create one backbone view and one model. However, if I think from server side Object's perspective, I need to create two backbone views and two models.

Could someone please tell me what are the things to be considered while dividing a page as different backbone views and models and kindly provide any references

1

1 Answers

1
votes

This depends on your REST API.

Backbone does not directly interact with backend tables, it usually uses a REST API that interacts with the tables (or whatever data storage).

If the API has endpoints for performing CRUD operations directly on a table, then you should create a backbone model client side representing it, and use it's built in methods such as save(), destroy() etc to interact with the REST API.

If your rest API returns data which is the result of joins of multiple tables, has single end points that updates multiple tables on backend, then it makes sense to have a model containing data from all those tables, and interact with the REST API using built in methods which updates all these tables accordingly.

So in short, you should create the frontend models according to the REST API, not directly according to the database structure.