Я делаю довольно сложное приложение emberjs и привязываю его к бэкэнду API.

Вызовы API обычно не привязаны к какой-либо конкретной модели, но могут возвращать объекты различных типов в разных разделах ответа, например, вызов API событий будет возвращать события, а также возвращать медиаресурсы и лиц, участвующих в этих событиях.

Я только начал проект, и я хотел бы получить некоторые экспертные рекомендации о том, как лучше разделить проблемы, чтобы иметь чистую поддерживаемую кодовую базу.

Я подхожу к этому так:

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.

Довольно часто мои шаблоны требуют привязки непосредственно к магазинам (например,peopleView хочет перечислить всех людей в индивидуальном магазине в списке, отсортированном по некоторому порядку).

И иногда они связываются с вычисляемым свойством

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

Различные варианты фильтрации и сортировки "выбраны" по мнению, должны возвращать разные списки из магазина. Вы можете увидеть мой последний вопрос наКак правильно emberjs переключаться между различными вариантами фильтрации?

Кто должен делать эту фильтрацию, просматривать себя или магазины?

Хорошо ли это связывание между слоями или запах кода? Хорошо ли разделение интересов или я что-то упустил? Разве контролеры не должны делать что-то еще здесь? Должны ли мои взгляды напрямую связываться с магазинами?

Какой-нибудь особый случай MVC больше подходит для моих нужд?

Update 17 April 2012 Мое исследование продолжается, особенно изhttp://vimeo.com/user7276077/videos а такжеhttp://jzajpt.github.com/2012/01/17/emberjs-app-architecture.html а такжеhttp://jzajpt.github.com/2012/01/24/emberjs-app-architecture-data.html

Некоторые проблемы с моим дизайном, которые я обнаружил:

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)

Это хороший пример государственных графиков в действии:https://github.com/DominikGuzei/ember-routing-statechart-example

UPDATE 9th JANUARY 2013

Да, это было давно, но этот вопрос в последнее время получает много просмотров, и поэтому я хотел бы отредактировать его, чтобы люди могли понять.

Пейзаж Ember сильно изменился с тех пор, как был задан этот вопрос, и новыйнаправляющие намного улучшены EmberJS придумал соглашения (например, Rails), и MVC теперь гораздо более четко определен.

Любой, кто все еще смущен, должен прочитать все руководства и посмотреть несколько видео: Сиэтл Ember.js Meetup

На данный момент я обновляю свое приложение доEmber.js 1.0.0-pre2.