I’ve put together this flow chart for a presentation I’m working on. I’m using it to explain how Ember implements MVC with the route as the director. I’m posting it here to make sure it’s clear & useful to others. Does this explain enough to be helpful? Is there more I could explain?
I’ve updated the flow chart based on feedback from @tomdale on Twitter. Sounds like Views will eventually be replaced by Components and the {{action}} helper. Does this make sense?
I think the best way to think about views is that they’re simply an implementation detail of how templates get rendered. I think it’s okay to say that templates get their state from the controller.
What is this about views going away? Sorry if this is old news, feel free to just point me to a resource.
Sorry, I didn’t mean to induce panic. 
Views aren’t “going away” in the sense that we are not going to remove them before the 1.0 release (which is in about a week), so we will continue to support them until 2.x.
However, with Handlebars templates getting more powerful, and with the introduction of components, there are very, very few use cases for which a view is still appropriate. They serve almost no value to the end user, while providing tremendous value internally as unified form of bookkeeping. I suspect views will always be around, even in 2.x (which, I should be clear, we’re not planning on having for at least a year or two) but purely as an internal concept that newbies won’t have to worry about.
What means “there is actualy no longer a need to use a view”? please someone explain that, I can’t have a shock in the sunday morning 
Dont Panic!
I think @tomdale is just saying that basically (component + handlebars) ~= better view, and that views are going to become an implementation detail as ember matures.
ah ok, thanks 
I feel better now…
@tomdale If I removed View from this chart, would it be useful to have somewhere in the Ember guides?
Does this mean Ember is no longer an MVC app?
@joefiorini this is great!
It would be very helpful to have a semi non trivial example posted in a JSBin somewhere.
I think nesting and some of the more advanced view management techniques need to be better documented.
For me personally, getting my head around controllerFor and setup controller semantics has been difficult. I think I tend to confuse router and controller. So this diagram helps.
The specific use case I am working through is to understand how to make very flexible modal dialogs. And specifically I would like to dynamically and programmatically render specific views. And looking for code examples to cement my understanding.
As far as extending this example. It could be helpful to include a concrete visual example of the lifecycle of some of the parts.
Controllers are long lived and are created or generated upon start up
Views and Templates are rendered on demand
Routes configure controllers when transitions and states change.
That kind of stuff.
I should also say the “needs” helper feels a little magical. But that is because I am still trying to understand it fully.
So perhaps showing how multiple views and templates could be associated with a single controller and/or vice versa would be useful to visualize.