Edit: Also, for folks looking for useful patterns, I'd recommend scrolling through and viewing source on a few of the increasingly lengthy list of example apps:
Pandora, Trajectory, and SeatGeek were added recently, and there are more that are waiting for a blurb, including Sky+ and GroupOn:
Thanks for the comment. Also, thanks a lot for Backbone, underscore, coffee and jammit. Half of our stack is your code :)
Yes, collection should keep track of the subviews. Not the view that initializes the collection
The link in this article in the first section "Models should not know about Views" should link instead to http://bit.ly/pfnFYu
(gotten from the github history)
Keep things decoupled with abundant usage of events.
* On client Backbone.sync does AJAX calls
* On server Backbone.sync talks to database
In some cases we also do Backbone.sync via socket.io
Note: Backbone.sync is the method all I/O operations on Backbone.js models and collections call. You can either use the default AJAX-based implementation that Backbone.js ships with, or override it with your own.
But models are generally just objects. They know how to handle and manage data. Nothing spectacularly complex.
As far as saving state goes there are different ways of doing it, the vanilla way backbone uses however seems to simply be making REST requests to the server.
You don't really have a request dispatcher on the client side (a controller). Instead, you have a View Model, which is basically a representation/manager of the View in JS code (where the View itself is HTML).
... it gets complicated.
JS has a wonderful MVC architecture built-in. all JS objects are models by defaults, all views (HTML elements) are models too, and JQuery has a lot of helper functions to simplify events.
These frameworks give you a good idea of how to organize your code better and help you standardize implementation, but if you know what you are doing, you can do it anyways.