Должен ли Угловой сервис иметь состояние?

Question

Должен ли Угловой сервис иметь состояние?

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

Причины для предоставления услуг:

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

Причины, по которым службы не сохраняются:

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

Один из способов, который мог бы адресовать номер 2 в разделе «Состояние обслуживания», - это иметь объект appState, установленный на rootScope, который содержит текущее состояние приложения. Тогда все государство будет собрано в одном месте, а затем вы просто вытащите то, что вам нужно, в вашем сервисе. Я нашел это и задался вопросом

18

добавлено 09 Январь 2013 в 04:35 автор testing123

Просмотры: 4

источник

nl ja de

4 ответы

Видеокурс по Java для начинающих

Получи видеокурс по Java для начинающих с упражнениями

Видеокурс "Создание приложений для Android"

Получи множество видеоуроков по Android сейчас

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

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

Взгляните на сервис $ http : вы можете получить экземпляр этого вызова службы

var x = $http({url:'...'});

И затем позвоните

var result = x.get() //actually `$http.get` is shortcut of this operation

То же самое с ngResource : используя службу, вы получаете объект с некоторым состоянием, которое может выполнять требуемые действия.

Поэтому я считаю, что это лучший вариант: с одной точки вы избегаете «побочных эффектов» путем перемещения состояния, которое может быть изменено действием на отдельный объект, а не храниться в самом сервисе, но может иметь определенное состояние в этом объекте, чтобы иметь возможность хранить пользовательскую информацию (например, информацию auth и т. д.).

9

добавлено 09 Январь 2013 в 06:02 автор Valentyn Shybanov

источник

Хорошие моменты о $ http и $ resource. Кроме того, мне нравится ваша мысль о сохранении состояния, которое не будет изменено функциями, вызываемыми службой (за исключением, может быть, при инициализации службы).

добавлено 09 Январь 2013 в 06:49, автор testing123, источник

Мини-курс по Angular и NgRx

16 видео-уроков

Инструменты успешного делегирования

Автор: Евгений Попов

автор Josh David Miller · Answer 1 · 2013-01-09T04:44Z

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

Например, если у вас есть служба, отвечающая за связь с API, эта служба может содержать состояние аутентификации.

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

автор ascotan · Answer 2 · 2014-01-07T04:42Z

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

Общей проблемой с состоянием службы является:

поток 1 записывает в состояние
поток 2 записывает в состояние
поток 1 читается из состояния
поток 2 читается из состояния

Поток 1 теперь имеет неправильное значение.

Это, как говорится, JavaScript в настоящее время однопоточный, поэтому у вас не будет проблем с доступом к потоку, подобных этому. Тем не менее, я был бы обеспокоен, если бы у меня была служба, в которой все асинхронные $ http-вызовы записывались в одну и ту же служебную переменную. Если бы только я мог лучше спать ночью, я бы попытался написать все свои методы обслуживания, чтобы они были сквозными данными для фактических данных.

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

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

автор Tiago Roldão · Answer 3 · 2013-01-09T05:42Z

ИМО да, услуги МОГУТ иметь состояния. Я говорю, что «может», поскольку услугу можно рассматривать как нечто похожее на классическую не клиентскую службу - провайдера, но это также может означать нечто совершенно иное, в angularJS. Как элемент rootScope-y one-instance в приложении, он может использоваться исключительно для управления состоянием, например. В моем случае это позволяет мне обеспечить, чтобы структура штата была одинаковой во многих приложениях, и хотя их индивидуальная структура состояния определена для каждого в процессе начальной загрузки, такие вещи, как состояние сеанса, всегда одинаковы и обновляются, когда этот модуль изменяется.