Understanding the relationship between controllers and routes in Ember

Question

I'm having a bit of trouble understanding the conceptual relationship between controllers and routes in an Ember application.

I've started down the path of a pretty simple spike test to evaluate Ember, and the deeper I get into it, the more I'm seeing my routes fill up with what I'd have through should be the controller's responsibility, such as actions, wiring up models, and ultimately dispatching to a view to render a template.

The controllers are all empty, and seem to be just a placeholder for some auto-mapping requirement.

Am I missing a fundamental thing here - coming from a Rails perspective, and applying (perhaps erroneously) the "rails way" to Ember I expected my routes to define states that are represented by URLs, which would map to a controller "action".

Any pointers would be much appreciated.

Answer 1

While the model classes handle the objects and their state, the controller handle the state of the application itself.

A very simple use case could be that you have two states for a form: readonlyMode and modifyMode. This belongs clearly not into the model where the actual objects are defined. It is just a state of your application.

If the controller says that the state is readonlyMode, the view will render all input fields as disabled. The reverse goes for the modifyMode.

But I agree that is not always easy to decide where to put it. At then end, MVC is about concepts. Having to to put it into some kind of rules, I would say:

• everything that represents persistent data (stored in some kind of storage/DB) is usually part of the model.
• everything that helps to make your application stateful => controllers.