Относительно типичного поведения контроллеров в Ember

Являются ли контроллеры в ember.js привязаны к основным областям/сценам a la iOS или более привязаны к набору данных?

Является ли общим/мудрым иметь несколько основных представлений, связанных с одним и тем же контроллером в ember?

В iOS основные части или разделы экрана привязаны к одному контроллеру. Если вы хотите представить другой основной интерфейс, скажем, модальное окно для создания нового элемента, вы, как правило, имеете совершенно отдельный контроллер для управления этим представлением и его данными/логикой.

В чем-то вроде Zend Framework у вас есть контроллеры, которые могут выполнять некоторые общие шаги отступов для обеспечения аутентификации, но в основном действия играют роль, которую выполняют контроллеры в iOS, обрабатывают логику и предоставляют данные для 1 основного раздела или представления ( будучи сетью, обычно это становится всей страницей).

Какова эта типичная роль или рекомендуемый шаблон для использования контроллеров в ember?

Ответ 1

У вас есть несколько разных вопросов, поэтому я буду обращаться к ним по одному.

Сначала вы спросили, должны ли контроллеры ориентироваться на данные или ориентироваться на них. По моему опыту оба поведения допустимы. Контроллеры - отличный способ управлять наборами данных для вашего приложения, включая такие функции, как фильтрация и поиск. Эвин Грано написал хорошую статью об этом с точки зрения SproutCore, и большинство концепций должно относиться и к Ember: http://www.itsgotwhatplantscrave.com/2009/07/30/root-controller-paradigm/. Контроллеры также хорошо подходят для управления состоянием и поведением приложения. Например, вы можете поместить метод в контроллер, который связан с действием кнопки в другом месте вашего приложения. Тем не менее, вы также должны изучить государства Ember, чтобы узнать, могут ли они лучше соответствовать вашему сценарию.

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

Ответ 2

Из моего ограниченного опыта работы в Ember.js я регулирую следующее:

Представление обрабатывает действия пользователя, связанные с изменениями уровня представления, ограниченным собственным экземпляром.
Контроллер/диспетчер навигации обрабатывает сложные манипуляции с представленным (добавляет несколько видов, удаляет другие и т.д.).
Контроллер реагирует на действия пользователя, связанные с уровнем данных.