EmberJS:Хорошее разделение задач для моделей, хранилищ, контроллеров и представлений в довольно сложном приложении?
Я делаю довольно сложное приложение emberjs и привязываю его к серверной части API.
Вызовы API обычно не привязаны к какой-либо конкретной модели, но могут возвращать объекты разных типов в разных разделах ответа, например. вызов Events API вернет события, но также вернет медиаресурсы и людей, причастных к этим событиям.
Я только начал работу над проектом и хотел бы получить рекомендации экспертов о том, как лучше всего разделить проблемы, чтобы иметь чистую кодовую базу, которую можно обслуживать.
Я подхожу к этому следующим образом::
- Модели:по существу обрабатывают записи с их полями и другими вычисляемыми свойствами. Однако модели не несут ответственности за выполнение запросов.
- напр. Индивидуальное, Событие, Изображение, Сообщение и т. д.
- Магазины:По сути, это кэши. Например,
eventStoreбудет хранить все события, полученные от сервера на данный момент (от возможных разных запросов)в массиве, а также в хэше событий, проиндексированномid.- напр. IndividualStore, eventStore и т. д.
- Контроллеры:Они привязаны к набору связанных вызовов API, например. Контроллер событий будет отвечать за получение событий или конкретного события, создание нового события и т. д. Они будут «направлять» ответ в разные
storesдля последующего извлечения. Они не сохраняют ответ после того, как он был отправлен в магазины.- напр. eventsController, userSearchController и т. д.
- Представления:Они привязаны к конкретному представлению. В общем, мое приложение может иметь несколько представлений в разных местах, например.
latestEventsViewна панели инструментов в дополнение к отдельной странице событий. - Шаблоны:такие, какие они есть.
Довольно часто,мои шаблоны требуют прямой привязки к магазинам (например. peopleViewхочет перечислить всех пользователей в IndividualStore в виде списка, отсортированного по некоторому порядку).
А иногда они привязываются к вычисляемому свойству.
alivePeople: function () {... }.property('App.individualStore.content.@each'),
Различные параметры фильтрации и сортировки, «выбранные» в представлении, должны возвращать разные списки из хранилища. Вы можете увидеть мой последний вопрос по адресу , каков правильный способ emberjs для переключения между различными параметрами фильтрации?
Кто должен выполнять эту фильтрацию, сами представления или магазины?
Такого рода привязка между уровнями допустима или пахнет кодом? Хорошо ли разделение проблем, или я что-то упускаю? Разве контроллеры не должны делать здесь что-то большее? Должны ли мои представления напрямую связываться с магазинами?
Какой-нибудь частный случай MVC больше подходит для моих нужд?
Обновление от 17 апреля 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
. Некоторые проблемы с моим дизайном, которые я выяснил, заключаются в том, что:
- контроллеры делают запросы, (хранилища, модели или что-то еще должны это делать, а не контроллеры)
- диаграммы состояний отсутствуют --они важны для просмотра-взаимодействий с контроллерами (через какое-то время вы понимаете, что ваши взаимодействия не более просты)
Это хороший пример диаграмм состояний в действии:https://github.com/DominikGuzei/ember-routing-statechart-example
ОБНОВЛЕНИЕ 9 ЯНВАРЯ 2013
Да, это было давно, но этот вопрос в последнее время получает много просмотров, и поэтому я хотел бы отредактировать его, чтобы люди могли понять.
Ландшафт Эмбера сильно изменился с тех пор, как был сформулирован этот вопрос, и новые руководства значительно улучшены. EmberJS придумал соглашения (, такие как Rails), и MVC теперь гораздо более четко определен.
Всем, кто все еще запутался, следует прочитать все руководства и посмотреть несколько видео.: Seattle Ember.js Meetup
В данный момент я обновляю свое приложение до Ember.js 1.0.0-pre2.