Ответ 1

Лучший ответ, который я могу вам дать, это:

Короче:

• Всякий раз, когда вы хотите выставить логику шаблону, используйте Scope.
• Всякий раз, когда вы хотите сохранить логику элемента, используйте ngController.
• Если вы хотите раскрывать значения своего контроллера непосредственно в шаблоне (через область действия), используйте "контроллер как синтаксис".

Длинные:

Объяснение

Scope или $scope, как вы выразили, мы поддерживаем значения (независимо от типа: Function, Object, String и т.д.), которые могут быть доступны шаблону в пределах этой области. Например, рассмотрим следующее:

HTML:

<div ng-controller="MyCtrl">
  <div>{{ message }}</div>
</div>

<div ng-controller="MyCtrl as ctrl">
  <div>{{ ctrl.message }}</div>
</div>

Смотрите эти интерполяции? Ну, угадайте, что? Они оба получают доступ к Scope. "Контроллер как синтаксис" создает псевдоним для MyCtrl и публикует его в локальной области. Как только элемент был связан, если вы посмотрите на $scope, вы действительно найдете свойство ctrl, которое выдает контроллер.

Javascript

function MyCtrl($scope) {
  $scope.message = "controller MyCtrl";
  this.message = "controller as syntax";
}

Где бы я ни использовал MyCtrl, эти два сообщения доступны. Но чтобы легко получить доступ к значению на самом контроллере, мы используем синтаксис "контроллер как псевдоним".

Они честно две разные методологии. Синтаксис контроллера как * позволяет разработчику помещать контроллер в область действия и более легко обращаться к указанному контроллеру. Таким образом, в конечном итоге все заканчивается на сфере. В противном случае, скажем, через функцию директивной ссылки вы должны получить доступ к контроллеру свойства require. Методы и свойства контроллера необязательно должны быть подвержены шаблону, а просто используются в логике. (Кроме того, вы можете получить доступ к контроллеру через функцию jqLite data()).

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

Масштаб и контроллер

Главное, чтобы рассмотреть, что дочерний контроллер может наследовать область его родителя. Самое приятное в том, что дочерняя область наследует этот бит свойств родительского контроллера от родителя.

<!-- ctrl1 -->
<div ng-controller="MyCtrl as ctrl1">
  <div>{{ ctrl1.message }}</div>
  <!-- ctrl2 -->
  <div ng-controller="MyCtrl as ctrl2">
    <div>{{ ctrl2.message }}</div>
  </div>
</div>

Обратите внимание, что оба используют один и тот же контроллер, но имеют разные псевдонимы. Теперь свойства контроллера передаются дочерним элементам через Scope. Таким образом, ребенок может получить доступ к родительскому элементу через его псевдоним. Таким образом, благодаря этому синтаксису вы можете четко видеть разделение двух экземпляров MyCtrl. Они оба имеют свойство message в своих областях, но их легко отличить, не копаясь через родителей, детей, братьев и сестер и т.д.

Заключение

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

Ответ 2

В документации Angular для ngController объясняются преимущества использования "контроллера как" и "инъекции". Вот что он говорит:

• Использование контроллера, поскольку делает очевидным, какой контроллер вы используете в шаблоне, когда к контроллеру применяются несколько контроллеров.
• Если вы пишете контроллеры в качестве классов, у вас есть более легкий доступ к свойствам и методам, которые появятся в области видимости, изнутри кода контроллера.
• Так как всегда есть a. в привязках вам не нужно беспокоиться о прототипных примитивах маскирования наследования.

С моей стороны я нашел использование "контроллера как" весьма полезным, поскольку он заставляет меня рассмотреть вопрос о том, будет ли код, который я добавляю в контроллер, более целесообразно добавить в службу или директиву.

Например: часы. Часы - это то, что вам следует избегать в контроллерах, но легкий доступ к $scope позволяет легко их настроить. Использование "controller as" заставило меня задуматься о том, действительно ли мне нужно делать часы. Обычно часы могут быть выполнены с помощью директивы. Это привело к созданию меньших контроллеров, которые только настраивали начальное состояние и обменивались данными с услугами, шаблон, который я нашел гораздо более работоспособным и поддерживаемым.

Ответ 3

Как указано в документации Angular, преимущества

• Использование контроллера, поскольку делает его очевидным, какой контроллер вы доступ в шаблоне, когда несколько контроллеров применяются к элемент.
• Если вы пишете контроллеры в виде классов, у вас есть более легкий доступ к свойствам и методам, которые появятся в области, изнутри кода контроллера.
• Так как всегда есть a. в привязках вам не нужно беспокоиться о прототипных примитивах маскирования наследования.

Мне очень нравится, так как это позволяет легко различать, с каким контроллером я в настоящее время обращаюсь.

Ответ 4

Я прочитал несколько блогов и пришел к выводу, что цель использования не смешивает $scope и это. Для этого есть причина, что "this" и $scope могут быть разными, они не всегда одинаковы, например, Если я определил контроллер на "this", и я вызову в него другой контроллер, тогда $scope будет настроен на контроллер, который я назвал, но "this" всегда будет текущим контекстом, который является контроллером, в котором я вызывал другой контроллер, Таким образом, в этом случае $scope и "this" не будут одинаковыми, и использование их взаимозаменяемо может привести к некоторому неработающему поведению.

Пожалуйста, исправьте меня, если я ошибаюсь.