Angular 8: Определить службу утилит как синглтон и с использованием методов c? - PullRequest
Новая
       7

Angular 8: Определить службу утилит как синглтон и с использованием методов c?

1 голос
/ 20 февраля 2020

Я сейчас начинаю с Angular 8. Теперь я хочу написать сервис, содержащий функции util ("CoreService"). Но мне интересно, как именно я должен это сделать, и каковы преимущества или недостатки различных вариантов:

  1. Должен ли я определить его как синглтон?
  2. Должен ли я определить функционирует как stati c методы (вызываемые CoreService.doSomething()) или я должен определить его как инъецируемый класс с не-stati c методами (внедренными в конструктор)?

Может быть, один из Опции более или менее влияют на производительность (память?).

Любой ответ высоко ценится!

Пока The_Unknown

1 Ответ

1 голос
/ 21 февраля 2020

Хорошо, давайте остановимся на Сервисах в Angular. Давайте сначала разберемся с некоторыми деталями.

Рекомендуемый способ создания служб - это использование интерфейса командной строки:

ng generate service foo/weather

Это создаст новую службу в src/app/foo/weather.service.ts - вместе со скелетом для ваших тестов. Если вы проверите этот код, вы увидите, что он выглядит примерно так: 

@Injectable({
  providedIn: 'root',
})
export class WeatherService {
  constructor() { }
}

1. Синглтон или нет

Теперь посмотрите выше на строку providedIn: 'root'. Таким образом, вы в основном говорите, что Angular должен предоставлять эту услугу на уровне root. В этом случае Angular создаст один общий экземпляр вашего WeatherService и внедрит этот единственный экземпляр в любой компонент, который его хочет. Кроме того, из документации Angular:

Регистрация поставщика в метаданных @Injectable () также позволяет Angular оптимизировать приложение, удаляя службу из скомпилированного приложения, если оно не установлено. t используется.

Так что это также может сэкономить вам немного пропускной способности.

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

@Component({
  selector:    'app-cities',
  templateUrl: './cities.component.html',
  providers:  [ WeatherService ]
})

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

@NgModule({
  providers: [
    WeatherService,
    AnotherService
  ],
  ...
})

В двух словах - вы контролируете, как вы хотите, чтобы ваш сервис - как одиночный или нет - со всеми вытекающими последствиями.

2. Stati c или методы экземпляра

На мой взгляд, это не совсем вопрос. Путь к go - использование методов экземпляра. В любом случае, это немного усиливается через внедрение зависимостей Angular. Компоненты, которые вы создадите, запросят экземпляр вашего сервиса. DI Angular предоставит один (синглтон или новый), и вы можете работать с ним как с любым другим экземпляром объекта: 

@Injectable({
  providedIn: 'root',
})
export class WeatherService {
  getTodaysTemperature() { return 7; }
}

@Component({
   ... // omitted for simplicity
})
export class TemperatureComponent {
  constructor(weatherService: WeatherService) {
      this.temperature = weatherService.getTodaysTemperature();
  }
}

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

...