Angular производительность с использованием службы или свойств и событий - PullRequest
1 голос
/ 27 мая 2020

В документах упоминается несколько способов взаимодействия компонентов:

https://angular.io/guide/component-interaction

Есть ли преимущество в производительности при использовании служб вместо свойств / событий или наоборот?

Я все еще новичок в Angular и использую службы для обмена данными между компонентами, но мне кажется, что это «глобализирует» данные, так что любой компонент может читать или писать в сервис, если он позволяет. Я рассматриваю возможность перехода на свойства / события как способ усиления объема данных и попытку ограничить службы для глобально используемых данных (например, журналов или других данных, которые действительно нуждаются в универсальном доступе).

Есть ли память <-> компромисс с процессором, чтобы сделать там?

Ответы [ 2 ]

0 голосов
/ 27 мая 2020

Вообще говоря, и в принципе, они служат разным целям.

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

С другой стороны, событие предназначено для «реакции» на вещи. Например, когда происходит событие щелчка, необходимо запустить и обработать обратный вызов, и его время жизни не привязано к времени жизни приложения, а, скорее, к времени жизни события и его обратного вызова.

Конечно, нет причин, по которым вы не можете смешивать два (например, наличие наблюдателя EventEmitter <> / RX внутри службы вполне нормально, если ваша служба является «реактивной»; например, когда она прослушивает соединение через веб-сокет и должна уведомить 1 -N подписчиков), но общий принцип дизайна должен заключаться в использовании службы / событий там, где они имеют смысл.

Кроме того, как вы упомянули, службы являются глобальными (в контексте / модуле), тогда как события и свойства обычно локализованы. По этой причине лучше всего использовать службы, где имеет смысл глобальное взаимодействие (например, общая инфраструктура), и использовать события / свойства там, где они должны быть локализованы.

Что я предлагаю:

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

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

* 1016 создайте слишком много «сервисов», которые действуют только как шлюз связи между вашими компонентами, где события / свойства (ввод и вывод) имеют больше смысла.
0 голосов
/ 27 мая 2020

Любая услуга также может быть привязана к модулю. Свойство providedIn директивы @Injectable() управляет объемом службы.

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

Что касается ЦП, у меня нет причин, по которым можно было бы различать использование ЦП в обоих сценариях ios. Только реализация хранилища данных повлияет на использование ЦП. Независимо от того, где находится этот магазин.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...