Coming from server-side MVC dev, the line "Views: The meat of our business logic occurs here." was surprising. I thought the point of MVC was to decouple the logic from the views.
PS: I'm about to start reading the new Javascript Web Applications book by Alex MacCaw as I'm very interested in learning more client-side development. This is very new to me.
... that's not always the case. I don't know if there's enough out there yet to establish a canon, but we try to keep most reusable business logic in the models, and leave views to UI concerns. If you want to browse around:
To rephrase, we found that most logic in our app was view/event/interaction-related, and we found that keeping that stuff in the views made more sense for us.
Comments
Coming from server-side MVC dev, the line "Views: The meat of our business logic occurs here." was surprising. I thought the point of MVC was to decouple the logic from the views.
PS: I'm about to start reading the new Javascript Web Applications book by Alex MacCaw as I'm very interested in learning more client-side development. This is very new to me.
Yeah, it seems weird, but that's the way it works in Backbone (at least for us). Views are more similar to iOS' UIViewController than a Rails view.
Backbone views handle event binding and rendering, so they're more similar to Rails controllers, if anything.
... that's not always the case. I don't know if there's enough out there yet to establish a canon, but we try to keep most reusable business logic in the models, and leave views to UI concerns. If you want to browse around:
https://github.com/documentcloud/documentcloud/tree/master/p...
To rephrase, we found that most logic in our app was view/event/interaction-related, and we found that keeping that stuff in the views made more sense for us.