Когда использовать вложенные контроллеры вместо сервисов в angularjs?

Я только начал использовать AngularJS, поэтому я не эксперт.

У меня есть div, который представляет правильную область моего представления html. В этом div у меня есть контроллер, т.е.

<div class="rightContainer" ng-controller="rightContainerCtrl">...</div>

Внутри этого div у меня есть таблица, область поиска и т. д. Каждая область внутри этого div имеет свои собственные контроллеры, это выглядит так:

<div class="rightContainer" ng-controller="rightContainerCtrl">
...
   <div class="search" ng-controller="searchCtrl">...</div>
...
   <div class="table" ng-controller="tableCtrl">...</div>

 </div>

область поиска, например, имеет свой собственный контроллер и является дочерним элементом rightContainerCtrl, потому что ему нужно изменить некоторый контент в родительском элементе (rightContainerCtrl), но div rightContainer растет, теперь он большой и содержит несколько вложенных контроллеров.

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

Это похоже на антишаблон объекта Бога (в данном случае контроллер Бога), так что я думаю, что вместо использования вложенных контроллеров я могу реорганизовать свой код, чтобы исключить контроллер rightContainerCtrl и вместо этого использовать службу (например, в фасаде шаблон проектирования), эта служба затем будет использоваться контроллерами вместо совместного использования переменных области видимости.

но поскольку я не эксперт AngularJs, я не уверен, прав ли я или лучше оставить этот родительский контроллер, может быть, я что-то упускаю, поэтому мой вопрос

Когда лучше использовать вложенные контроллеры (вложенные области видимости), а когда вместо этого лучше использовать сервисы в angularjs?


person Miguel A. Carrasco    schedule 22.07.2013    source источник


Ответы (2)


Иерархия контроллера/области не должна диктовать, как данные/модели совместно используются в приложении. Когда вы думаете об обмене данными в Angular, подумайте о внедрении зависимостей.

В видео, на которое есть ссылка в ответе @shaunhusain, Миско заявляет, что область должна относиться к модели, а не быть моделью, поэтому не моделируйте/не помещайте свои данные в области. Ваши модели/данные обычно должны находиться в сервисе.

При написании приложения Angular сначала подумайте о своих моделях. Поместите их в сервисы с API, чтобы получить /редактировать/манипулировать моделями. Затем спроектируйте свои представления. Каждое представление должно проецировать/использовать/манипулировать некоторым подмножеством ваших моделей. Определите контроллер для каждого представления, который просто приклеивает необходимое подмножество моделей к представлению. Сделайте ваши контроллеры как можно тоньше.

(Именование контроллера rightContainerCtrl также не рекомендуется. Контроллер не должен знать о представлении/макете.)

person Mark Rajcok    schedule 22.07.2013
comment
Спасибо за ваш ответ, на самом деле контроллеры не должны знать о представлении, поэтому в этом смысле только потому, что представлению нужна иерархия div, это не означает, что контроллеры должны быть вложены, потому что они должны быть отделены/независимы от Просмотры. - person Miguel A. Carrasco; 23.07.2013
comment
Кроме того, если у вас есть контроллер и набор дочерних контроллеров, вероятно, вы используете область родительского контроллера в качестве модели, и это плохая практика, в этом случае требуется служба, а не родительский контроллер. - person Miguel A. Carrasco; 23.07.2013

Это 100% суждение, и оно должно быть основано на нескольких моментах.

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

Однако, если у вас все в порядке с контроллерами, каждый из которых зависит от службы (на самом деле это не проблема), вы можете просто использовать службу как средство передачи изменений между контроллерами. Я видел множество аргументов против синглтона (разновидностью которого является сервис, внедренный синглтон, но, тем не менее, синглтон). Я нахожу эти аргументы в основном спорными и, как правило, не имеют действительно элегантного и лаконичного решения. Если спор идет снова и снова о том, что, когда вы идете из A в D, вы не хотите идти по дороге B, но они, кажется, никогда не предлагают дорогу C, я действительно не вижу смысла.

http://www.youtube.com/watch?v=ZhfUv0spHCY&t=30m34s

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

person shaunhusain    schedule 22.07.2013
comment
Спасибо, что поделились этим видео, я посмотрел его, и теперь я лучше разбираюсь в AngularJs. Марк Райкок показал хороший момент в своем ответе, а также видео объясняет это. Вы должны использовать службы для своей модели, и ваша модель должна быть отделена от контроллеров и областей, поэтому в моем примере это rightContainerCtrl — это модель, потому что несколько вложенных контроллеров используют переменные в этой области, но это плохая практика, вместо этого это должна быть услуга. - person Miguel A. Carrasco; 23.07.2013
comment
@MiguelA.Carrasco Да, я рад, что вы тоже что-то вынесли из видео. Я недавно много рекомендовал его здесь, так как кажется, что оно охватывает множество распространенных ошибок. Я также добавил +1 к ответу Марка, он хорошо объяснил, и у него есть много других очень хороших ответов. - person shaunhusain; 23.07.2013
comment
Написание событий для связи между контроллерами — это, безусловно, боль. Я бы предпочел использовать для этого вложенные области. Или услуги. - person ColacX; 22.04.2015