Controllers vs Routes


Hi all,

I’m starting with ember js, and I have a question regarding the best practice…I went through the basic examples and after few minutes I’ve got a solid grasp of building fully featured client MVC application…I’m experienced Apache Wicket developer, so templating with handle bars looks a little familiar to me…:-), but:

I didn’t understand what is the best practice of regarding the Controllers, when do I need to define own controller? Controllers catches all actions from templates and defines data binding to templates, but Routes also define data binding through models, when doing data binding, when is better to use Controller and when Route?

thanks a lot in advance for clarification.



HI @Tomas,

Regarding Data binding, as per the emberjs guides,

In Ember.js, controllers allow you to decorate your models with display logic. In general, your models will have properties that are saved to the server, while controllers will have properties that your app does not need to save to the server.

So controller is where you define data binding to variables on your templates. Regarding data binding in routes, I guess you are referring to model hook, this guide explains it more appropriately.

Regarding actions,

All actions triggered on a template are first looked up on the controller, if it is not handled or bubbled (by return true) in the controller, they are looked up on the route. So I define actions that are common to more than one child routes on their common parent route. Refer action bubbling.

I am an Ember newbie too. I hope my answer was useful.


Routes are a sort of super controller that encapsulates and manages the state of the application. It creates the route controller and view and sets a model on the controller if you implement the model hook.

The controller wraps the model and provides computed properties and handles actions that change data. It is a matter of style, but it is probably best to make all model (store) and application state changes (transitions) in the route and use the controller to proxy the model and handle actions that do not change application state.


I recommend this video to everyone who is getting started with it helps a lot to understand what belongs where and which are the responsibilities of every components.

If you have a Rails background I wrote this post a while ago which might help you to map things,


Thank you guys for excellent answers, it helped a lot.