Почему DI делается в классе Constructor в Angular?

Question

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

Например, например: - какой-то DemoService класс должен использоваться в некоторых DemoComponent ,Экземпляр службы обычно создается в конструкторе класса.

@Injectable()
export class DemoService {
 ...
}

DemoComponent

@Component({
  selector: 'app-demo',
  templateUrl: './demo.component.html',
})
export class DemoComponent implements OnInit {
  ...
  constructor(
    private demoService: DemoService 
  ) {}
  ...
}

Итак, мой вопрос такой:Можем ли мы создать экземпляры сервисов внутри ngOnInit() метода ловушки жизненного цикла?

Делать что-то вроде - или в каком-нибудь другом месте.

ngOnInit() {
    // using new DemoService();
}

Спасибо.

Answer 1

Одной из причин, по которой я могу думать о DI, являются параметры обслуживания constructor (DI для обслуживания).Когда вы внедряете сервис внутри компонента, используя DI, вам больше не нужно беспокоиться о параметрах сервиса constructor, если таковые имеются.Angular обрабатывает его самостоятельно.

Например:

service

@Injectable()
export class DemoService {
    constructor(myService : MyService){}
}

Так что, если у вас есть сервис, подобный описанному выше, если вы не используете DI, тогдаВы заботитесь о параметре myService здесь.

Например, вы будете выполнять

компонент

constructor(){
  let myService = new MyService();
  this.demoService = new DemoService(myService)
}

Все в порядке, если вы написали свой собственный сервис.

Что если вы используете его из какой-то библиотеки ??Вы не знаете, какой параметр передать

Answer 2

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

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

---

Ниже приведены проблемы с классом, создающим экземпляры зависимостей.и как DI Angular решает это:

1. трудно поддерживать .Если конструктор зависимости изменяется, то нам придется распространить это изменение на все места в коде, где был создан экземпляр этого класса.

Рассмотрим этот код с ЗАВИСИМОСТЬ ЗАВИСИМОСТИ В ANGULAR - от Thoughtram, например:

class Car {
  constructor() {
    this.engine = new Engine();
    this.tires = Tires.getInstance();
    this.doors = app.get('doors');
  }
}

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

РЕШЕНИЕ: ЕслиМы полагаемся на Angular Injector, чтобы предоставить нам эти зависимости, это будет выглядеть примерно так:

class Car {
  constructor(engine, tires, doors) {
    this.engine = engine;
    this.tires = tires;
    this.doors = doors;
  }
}

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

Это трудно для юнит-теста .Как упомянуто Паскаль в его статье :

Представьте, что вы хотитечтобы проверить этот класс.Как бы вы заменили Engine с зависимостью MockEngine в этом коде?При написании тестов мы хотим тестировать различные сценарии, в которых используется наш код, поэтому каждый сценарий требует своей собственной конфигурации.Если мы хотим написать тестируемый код, нам нужно написать повторно используемый код.Наш код должен работать в любой среде, если все зависимости удовлетворены.Что приводит нас к выводу, что тестируемый код является кодом многократного использования и наоборот.

РЕШЕНИЕ: Если мы используем DI-код Angular, код будет выглядеть примерно такВот это:

var car = new Car(
  new MockEngine(),
  new MockTires(),
  new MockDoors()
);

Посмотрите, как легко было бы создать макет любой из наших зависимостей.

Это не синглтон .Все созданные зависимости будут локальными для класса.Таким образом, вы не сможете использовать один сервис для нескольких классов, если захотите.Совместное использование данных будет сложным для управления, и это сделает всю установку более сложной.Часы "Почему инъекция зависимости" от kudvenkat чтобы узнать больше.

РЕШЕНИЕ: Если мы полагаемся на инжектор Angular для этих зависимостей, мы можем быть уверены, что инжектор Angular предоставит нам Singleton, если не указано иное (в случае, если вы добавили услугу к providers компонента)

---

Я снова связываю несколько ресурсов, которые были бы чрезвычайно полезны для понимания DI в Angular:

1. ВПРЫСК ЗАВИСИМОСТИ В УГЛОВОЙ
2. Инъекция угловой зависимости
3. Почему инъекция зависимости

Answer 3

Как правило, этого не может произойти в ngOnInit().Механизм DI Angular должен строить дерево зависимостей из внедренных зависимостей, когда он загружается.Ему нужно знать

1. все объекты, которые он должен создать, и
2. , в каком порядке он должен создавать объекты, и
3. все точки внедрения зависимостей, которые он создает..

Когда мы используем DI Angular, мы позволяем Angular создавать и управлять объектами для нас.Мы не делаем это сами.Это имеет то преимущество, что делает код очень тестируемым среди других преимуществ.

Создание экземпляра DI и объекта происходит в конструкторе, поскольку именно тогда создаются фактические объекты и зависимости объектов.

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

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