Поддерживает ли ember.js слишком много контроллеров?

Ответ 1

Я думаю, что говоря, что Ember поощряет слишком много контроллеров, это похоже на то, что Javascript поощряет слишком много функций. Да, вы можете сходить с ума от распространения. Или вы можете сделать наоборот, и работать он точно так, как вам нужно. В общем, всегда помните, что ваше приложение должно быть таким же сложным, каким оно должно быть, и не более того. Вам не нужно использовать определенную архитектуру или шаблон только потому, что какой-то знаменитый парень-кодер использовал его, даже не потому, что это, по-видимому, "путь Ember". Даже "Универсальные добрые дела", такие как "Разделение проблем", "MVC" и т.д., Являются принципами и моделями, которые вы должны попытаться полностью понять, а затем использовать в той мере, в какой они служат вашим потребностям. Я думаю, что способность избирательно нарушать правила и шаблоны по правильным причинам гораздо более знаменует признаком великого хакера, чем рабская преданность догме богов программирования. Это ремесло, а не религия. (Но YMMV. Возможно, там специальный круг ада зарезервирован для таких кодеров, как я. Я держу пари против него.)

Специфично для Ember, я склонен использовать контроллеры вокруг своих моделей данных и/или вокруг определенного пользовательского рабочего процесса, а не вокруг каждого представления. Затем используйте Routing/State Managers как клей между вашими представлениями, и я обычно использую Event Managers для просмотра событий браузера в каждом представлении, включая отправку инструкций маршрутизатору. Итак, если у меня есть приложение, которое вращается вокруг, скажем, "Клиенты и продукты", у меня будет контроллер для каждого, как я обычно делаю в Rails. Это приведет к тому, что каждый контроллер будет содержать больше функций и вычисляемых свойств, чем некоторым людям нравится иметь в одном месте. Это также означает, что я не могу повторно использовать свои взгляды в другом контексте, потому что они жестко подключены к контроллеру. И да, это плохо. Разделение проблем. Но это не абсолютное благо, если оно вызывает сложность, которая не имеет никакой отдачи.

Кроме того, по теме контроллеров, я думаю, что люди особенно склонны излишне распространять контроллеры для подмножеств вашей основной модели данных. Скажем, у вас есть контроллер продуктов, и вы хотите хранить продукты, которые данный пользователь собирает в инструменте сравнения. Большинство людей, похоже, создают для этого новый контроллер, но вполне законно подталкивать их к дополнительному массиву или другому перечислимому внутри контроллера вашего продукта или контроллера клиентов или модели клиента. Это сохраняет объекты, которые полагаются на одни и те же функции и свойства в более близком масштабе. Объект content в каждом контроллере - AFAIK, только один перечислимый. Он содержит несколько специальных скрытых ссылок на контроллер, но не является магии. Там нет функциональной причины, по которой я не использовал дополнительные. Они работают также с привязками, с #each и т.д.

Аналогично, некоторые люди просто ЛЮБЯТЬ, чтобы разорвать свое приложение на миллион файлов, вложить их в глубину в структуру файла и т.д. Больше энергии для вас, если это поможет вам визуализировать основную логику и дать понять, остальную часть вашей команды. Для меня это просто замедляет работу над проектами только с командой инженеров 1-3 человек. Люди также склонны воспроизводить стиль на основе файлов других систем MVC, с которыми они знакомы (например, Rails), где файлы являются необходимой явной структурой для разделения представлений и других логических объектов. Это становится предметом веры и глубоко укоренившейся привычкой. Но в Javascript MVC я обнаружил, что он часто не выполняет такой цели и строго избыточен для неявного дизайна. Я использую один, тщательно организованный файл для всего приложения Ember (отделяя его от любых других небиблиотечных JS), с большим количеством отступов и вложенности, где это помогает мне визуализировать иерархию. Независимо от того, что вы делаете, по файлу, все равно во время выполнения, при условии, что вы доставляете все это в нужное место в нужное время. С Ember и JS файловая структура предназначена для нужд вашей команды, и ничего больше. Откалибруйте соответственно.

(ВАЖНАЯ ПЛОЩАДЬ: если вы используете миллион файлов, лучше использовать предварительный компилятор, чтобы отобразить их все вместе для доставки пользователю, или вы сделаете огромный латентный удар по доставке всех эти файлы отдельно.)

(ДРУГАЯ ВАЖНАЯ ПЕЧЬ: с большой командой или быстрые ежедневные расписания, такие как GitHub, разделение на основе файлов вашей логики может упростить управление версиями, чем делать много слияний в один и тот же файл, где ваш инструмент слияния может запутаться. Опять же, это проблема управления и мониторинга ваших человеческих процессов, а также тщательного слияния, а не технического требования, предъявляемого вашей инфраструктурой JS.)

(ПОСЛЕДНИЙ ВАЖНЫЙ ПЕШЕХОД: Опять же, иногда разница между техническим требованием и требованием к человеку/процедуре нечеткая. Если вы нарушаете мозг разработчика, у вас также есть сломанное приложение. Итак, сделайте то, что работает для людей и процессов, с которыми вам приходится иметь дело при создании.)

Как я уже говорил, YMMV. Я не кодер Бога, как вы можете сказать из моего рейтинга репутации, так что вы можете свободно игнорировать меня. Но я не согласен с тем, что вы должны использовать только такую ​​сложность, как много файловой структуры, и только столько абстракций более высокого уровня (например, маршрутизация, которая может быть переполнена для одностраничных приложений ограниченного назначения) твои нужды; и не более.

Ответ 2

Я думаю, что мы разрабатываем довольно большое приложение ember (около 45 просмотров на данный момент). Это подразумевает почти то же количество контроллеров и шаблонов). На самом деле наш маршрутизатор довольно большой, но мы справляемся с ним довольно легко, разбивая его на многие файлы. В принципе, каждый файл представляет собой один экран приложения и отвечает за поддержание функционального набора. Вот выдержка из маршрутизатора:

Router = Ember.Router.extend({
  root: Ember.Route.extend({

  index: Ember.Route.extend({
    route: '/',

  unlogged: Ember.Route.extend({
    route: 'welcome',

    connectOutlets: function (router) {
      var applicationController = router.get('applicationController');
      applicationController.connectOutlet('welcome');
    }
  }),

  logged: Ember.Route.extend({
    route: 'app',

    projects: Ember.Route.extend({
      route: 'projects',

      collection: ProjectsRoute,
      member: ProjectRoute,

      showProjects: function (router) {
        router.transitionTo('projects.collection');
      }
    })
  })
})

Тогда это то же самое в ProjectRoute. Каждый раз, когда кажется, что у многих есть функция в одном маршруте, мы его разделяем. Вы даже можете снова открыть маршрут для его расширения и подключить к нему другую функциональную функцию.

ProjectState.reopen({

  scenarios: ScenariosRoute,

  showScenarios: function (router) {
    router.transitionTo('scenarios.collection');
  }
});

Это подразумевает больше файлов, но с хорошей организацией, их трудно поддерживать, так как очень редко вы работаете со всеми функциями одновременно. Обычно у меня есть еще 4 открытых файла одновременно (просмотр, контроллер, шаблон, маршрут)

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