EmberJS: Good separation of concerns for Models, Stores, Controllers, Views in a rather complex application?

Question

I'm doing a fairly complex emberjs application, and tying it to a backend of APIs.

The API calls are not usually tied to any particular model, but may return objects of various types in different sections of the response, e.g. a call to Events API would return events, but also return media assets and individuals involved in those events.

I've just started with the project, and I'd like to get some expert guidance on how best to separate concerns to have a clean maintainable code base.

The way I am approaching this is:

Models: essentially handle records with their fields, and other computed properties. However, models are not responsible for making requests.
- e.g. Individual, Event, Picture, Post etc.
Stores: They are essentially caches. For example, an eventStore would store all events received from the server so far (from possibly different requests) in an array, and also in an hash of events indexed by id.
- e.g. individualStore, eventStore etc.
Controllers: They tie to a set of related API calls, e.g. eventsController would be responsible for fetching events or a particular event, or creating a new event etc. They would 'route' the response to different stores for later retrieval. They don't keep the response once it has been sent to stores.
- e.g. eventsController, userSearchController etc.
Views: They are tied to a particular view. In general, my application may have several views at different places, e.g. latestEventsView on the Dashboard in addition to having a separate events page.
Templates: are what they are.

Quite often, my templates require to be bound directly to the stores (e.g. peopleView wants to list all the individuals in the individualStore in a list, sorted by some order).

And sometimes, they bind to a computed property

alivePeople: function () { ... }.property('App.individualStore.content.@each'),

The various filtering and sorting options 'chosen' in the view, should return different lists from the store. You can see my last question at what is the right emberjs way to switch between various filtering options?

Who should do this filtering, the view themselves or the stores?

Is this kind of binding across layers okay, or a code smell? Is the separation of concerns good, or am I missing something? Shouldn't controllers be doing something more here? Should my views directly bind to stores?

Any particular special case of MVC more suited to my needs?

Update 17 April 2012 My research goes on, particularly from http://vimeo.com/user7276077/videos and http://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html and http://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Some issues with my design that I've figured out are:

controllers making requests (stores or models or something else should do it, not controllers)
statecharts are missing -- they are important for view-controller interactions (after sometime you realize your interactions are no more simple)

This is a good example of state charts in action: https://github.com/DominikGuzei/ember-routing-statechart-example

UPDATE 9th JANUARY 2013

Yes, it's been long but this question is lately getting lots of views, and that's why I'd like to edit it so that people may get a sense.

Ember's landscape has changed a lot since this question was framed, and the new guides are much improved. EmberJS has come up with conventions (like Rails) and the MVC is much more well defined now.

Anybody still confused should read all the guides, and watch some videos: Seattle Ember.js Meetup

At the moment, I'm upgrading my application to Ember.js 1.0.0-pre2.

I have been working through alot of these same types of questions. related: stackoverflow.com/questions/10045619/… — Nick Franceschina
Again, this sort of information is where EmberJS lacks at the moment. I've only started working with EmberJS yesterday and have literally been frustrated to the point of pulling out my hair because there is absolutely nothing about how EmberJS should be setup and what each type of object is responsible for - or at least: it's very hard to find. — Lennard Fonteijn
not using ember-data, since the backend of APIs is not that RESTful as it should've been. So I decided to write models & stores myself. — Kazim Zaidi
This is almost answered. And the answer is Ember.js guides. Maybe I'd just accept any answer that says just that ;-) — Kazim Zaidi

ken ken · Accepted Answer · 2013-01-23T06:35:01

You should think of your application in terms of states. Have a look at this
Initially, only a route and a template are required to describe something and finally display it in the browser, that's what the new API of Emberjs tries to enforce. As your requirements get more elaborate you can throw in a view, a controller or an object. Each though answers a specific need.
Consider a view if you need to handle any browser events or wrap
any 3rd party javascript lib you're using for animation, styling ..
Consider an Object if you need to capture domain specific
information, most likely mimics backend information.
A controller is merely a proxy for the domain object and may encapsulate logic that doesn't pertain necessarily to the object.

That's all what's to it. If you learn how to design your application in terms of states, the rest will fall into the right place, providing you're using the latest api, enforcing the rules i mentioned previously.

EmberJS: Good separation of concerns for Models, Stores, Controllers, Views in a rather complex application?

3 Answers