3 ms·

Amen. Except... the current trend I'm seeing/hearing is "nothing in controllers". There seems to be some hatred of controllers controlling anything.

• neeleshs 13y ago
  The reason is that the code in controllers tend to be view specific in practice, to the extent of projecting view specific models. If you wanted to expose your business logic as APIs, you are better off either writing controllers view agnostic, or pushing down the business logic to something else.
• TylerE 13y ago
  I think there is a certain amount of "those who do, do, those who can't, teach" going around in the framework space. To-Do List apps and Photo Galleries don't have business logic.
  • dustingetz 13y ago
    Todo lists do have business logic, but the logic is so simple that one might not notice when it gets coupled to the views. so you can get away with coupling things like "MV-whatever" or MVVM for apps up to a certain threshold. Facebook is an example of an app well past that threshold, so we should probably listen to them when they talk about their new DOM management library, Facebook React.
• rgbrgb 13y ago
  One of the big ideas for me was that the controller is the least reusable, most application specific piece. With that in mind, keeping the bulk of the business logic and view logic in highly testable and reconfigurable models and views makes a lot of sense. I think of a controller as a mapping between model and view -- it takes internal state and pipes it to some views then takes external stimuli and pipes it to some models.
  • dustingetz 13y ago
    exactly, and the application specific-ness is what makes them hard or poorly understood. General DOM management libraries can't provide a controller. For one thing, it needs to interface with your backend.