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

MVC и его производные (MVP, PM, MVVM) все хороши и Денди в рамках одного агента, но архитектура сервер-клиент для всех целей является двухагентной системой, и люди часто настолько одержимы этими шаблонами, что забывают, что проблема гораздо сложнее. Стараясь придерживаться этих принципов они на самом деле в конечном итоге с ущербной архитектурой.

давайте сделаем это по крупицам.

руководство

вид

в угловом контексте вид является DOM. Руководящие принципы:

Do:

• присутствует переменная (только чтение).
• вызовите контроллер для действий.

нет:

• поставить какой-либо логики.

как заманчиво, коротко, и безобидно это выглядит:

ng-click="collapsed = !collapsed"

это в значительной степени означает, что любой разработчик теперь, чтобы понять, как работает система, им нужно проверить как файлы Javascript, так и HTML.

контроллеры

Do:

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

нет:

• интернет с любой бизнес-логикой.

причина последнего руководства заключается в том, что контроллеры являются сестрами для представлений, а не сущностями; и они не являются многоразовыми.

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

конечно, иногда взгляды представляют сущности, но это довольно специфический случай.

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

таким образом, контроллеры в Angular действительно больше Модель Презентации или MVVM.

и так, если контроллеры не должны иметь дело с бизнес-логикой, кто должен?

что такое a модель?

ваша клиентская модель часто является частичной и устаревшей

если вы не пишете автономное веб-приложение или приложение, которое ужасно просто (несколько объектов), ваша клиентская модель, скорее всего, будет:

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

реальная модель должна сохраняться

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

последствия

два пункта выше должны служить предостережением-модель, которую держит ваш клиент, может включать только частичную, в основном простую бизнес-логику.

таким образом, возможно, разумно в контексте клиента использовать нижний регистр M - так это правда mVC,mVP и mVVm. Большой M для сервер.

бизнес-логики

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

• логика или бизнес-правила предприятия, логика, которая не зависит от приложения. Например, дайте модель с firstName и sirName свойства геттера как getFullName() можно считать независимым от приложения.
• логика приложения или бизнес-правила приложения, который является специфичным для приложения. Например, проверка и обработка ошибок.

важно подчеркнуть, что оба они в контексте клиента являются не "реальная" бизнес-логика - они имеют дело только с той его частью, которая важна для клиента. Логика приложения (не логика домена) должна иметь ответственность за облегчение связи с сервером и большинство взаимодействий с пользователем; в то время как логика домена в основном является мелкомасштабной, специфичной для сущности и управляемой презентацией.

вопрос все еще остается - где вы бросаете их в угловом приложении?

3 против 4 уровня архитектуры

все эти рамки MVW используют 3 слоя:

но есть две фундаментальные проблемы с этим, когда дело доходит для клиентов:

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

альтернативой этой стратегии является стратегия 4 слоя:

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

этот слой реализуется интеракторы (дядя Вася), который является довольно много, что Мартин Фаулер вызывает рабочий скрипт сервисного слоя.

конкретный пример

рассмотрим следующее веб-приложение:

• приложение показывает разбитый на страницы список пользователей.
• пользователь нажимает кнопку 'Добавить пользователя'.
• откроется модель с формой для заполнения сведений о пользователе.
• пользователь заполняет форму и нажимает кнопку Отправить.

несколько вещей должно произойти теперь:

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

куда мы все это бросим?

если ваша архитектура включает контроллер, который вызывает $resource, все это будет происходить в контроллере. Но есть и получше стратегия.

предложенное решение

на следующей диаграмме показано, как проблему выше можно решить, добавив еще один логический слой приложения в угловые клиенты:

поэтому мы добавляем слой между контроллером в $resource, этот слой (назовем его interactor):

• это сервис. В случае пользователей, это может называться UserInteractor.
• оно обеспечивает методы соответствует варианты использования,инкапсуляция логики приложения.
• это управления запросы к серверу. Вместо контроллера, вызывающего $resource с параметрами свободной формы, этот уровень гарантирует, что запросы, сделанные к серверу, возвращают данные, на которых может действовать логика домена.
• он украшает возвращенную структуру данных с логика прототип.

и так, с требования конкретного примера выше:

• пользователь нажимает кнопку 'Добавить пользователя'.
• контроллер запрашивает у интерактора пустую модель пользователя, которая украшена методом бизнес-логики, например validate()
• после представления контроллер вызывает модель validate() метод.
• если не удалось, контроллер обрабатывает ошибку.
• в случае успеха контроллер вызывает interactor с помощью createUser()
• в interactor вызывает $resource
• после ответа, interactor делегирует любые ошибки контроллеру, который обрабатывает их.
• после успешного ответа, interactor гарантирует, что при необходимости, список пользователей обновляется.

незначительная проблема по сравнению с большими советами в ответе Артема, но с точки зрения читаемости кода я нашел лучше всего определить API полностью внутри return объект, чтобы свести к минимуму переход туда и обратно в коде, чтобы посмотреть wheverer переменные определены:

angular.module('myModule', [])
// or .constant instead of .value
.value('myConfig', {
  var1: value1,
  var2: value2
  ...
})
.factory('myFactory', function(myConfig) {
  ...preliminary work with myConfig...
  return {
    // comments
    myAPIproperty1: ...,
    ...
    myAPImethod1: function(arg1, ...) {
    ...
    }
  }
});

Если return объект становится выглядеть "слишком переполненным", что является признаком того, что служба делает слишком много.

в AngularJS делаешь не внедрить MVC в традиционный способ, а он реализует что-то ближе к шаблон MVVM(модель-представление-модель представления), модель представления может также рассматриваться как связующее(в угловой шкаф, он может быть $охвата). Модель--> как мы знаем модель в angular может быть просто старые объекты JS или данные в нашем приложении

представление--> представление в angularJS-это HTML, который был проанализирован и скомпилирован angularJS путем применения директив или инструкций или Привязок, главное здесь в angular вход-это не просто простая строка HTML (innerHTML), а DOM, созданный браузером.

ViewModel--> ViewModel на самом деле является связующим/мостом между вашим представлением и моделью в случае angularJS это $scope, для инициализации и увеличения $scope мы используем контроллер.

Если я хочу обобщить ответ: в приложении angularJS $scope есть ссылка на данные, контроллер управляет поведением, а представление обрабатывает макет, взаимодействуя с контроллер должен вести себя соответственно.

чтобы быть четким в вопросе, Angular использует различные шаблоны проектирования, с которыми мы уже сталкивались в нашем регулярном программировании. 1) Когда мы регистрируем наши регуляторы или директивы, фабрику, обслуживания etc по отношению к нашему модулю. Здесь он скрывает данные из глобального пространства. А это модуль pattern. 2) когда angular использует свою грязную проверку для сравнения переменных области, здесь он использует Шаблон Observer. 3) все родительские дочерние области в нашем контроллеры использует прототипная модель. 4) в случае введения услуг, которые он использует Шаблон Фабрики.

в целом он использует различные известные шаблоны проектирования для решения проблем.