Инъекция зависимости, состав root и точки входа

Question

Я потратил много времени на чтение этих статей (наряду со многими другими):

• Марк Симанн - PI DI

• Марк Симанн - Когда использовать DI-контейнер

• Марк Симанн - Составлять графы объектов с уверенностью

• Марк Симанн - Не вызывайте контейнер; он позвонит вам

• Марк Симанн - Понимание композиции Root

и я Я все еще пытаюсь обернуть голову вокруг DI и концепции «разводки зависимостей» и «автоматической разводки» функциональности контейнера Io C.

Мне кажется, я понимаю теорию внедрения зависимостей и Инверсия управления и я реализовал пример, показанный здесь с 2016 года (я обновил код для использования PSR-11 и исключил необходимость в пакете container-interop):

• https://www.sitepoint.com/how-to-build-your-own-dependency-injection-container/

Применение примера контейнера показано по ссылке GitHub: https://github.com/sitepoint-editors/Container.

Обратите внимание, что хотя в этом примере используется PHP, я пытаюсь понять детали DI независимо от языка, поэтому любой язык приветствуется.

Может кто-нибудь объяснить разницу между проводкой вручную зависимости и использование функции автоматического подключения контейнера? В статье SitePoint кратко упоминается, что более продвинутые контейнеры добавляют функциональность автоматического подключения c, подразумевая, что пример уже не содержит эту функцию. Может кто-нибудь объяснить приложение, показанное на странице GitHub, и как это относится к основным понятиям DI и Io C, например, Composition Root.

Answer 1

Может кто-нибудь объяснить разницу между ручным подключением зависимостей и использованием функции автоматического подключения контейнера?

Чистый DI - это практика применения DI без использования контейнера DI. Это означает, что вы строите граф объектов путем обновления объектов с использованием конструкции new вашего языка программирования. См., Например, этот пример в C# (из списка 12.2 книги Марка Принципы, практики и схемы внедрения зависимостей ):

new HomeController(
    new ProductService(
        new SqlProductRepository(
            new CommerceContext(connectionString)),
        new AspNetUserContextAdapter()));

В соответствии с этим книга Auto-Wiring:

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

Другими словами, с помощью DI-контейнера вы сможете «просто» сообщить контейнеру о ваших типах и он выяснит, какие зависимости тип имеет и сможет «связать» этот тип со своими зависимостями.

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

var container = new AutoWireContainer();

container.Register(typeof(IUserContext), typeof(AspNetUserContextAdapter));
container.Register(typeof(IProductRepository), typeof(SqlProductRepository));
container.Register(typeof(IProductService), typeof(ProductService));
container.Register(typeof(CommerceContext), () => new CommerceContext(connectionString));

И когда вы запрашиваете HomeController, контейнер знает, как построить весь график.

SitePoint a В статье кратко упоминается, что более продвинутые контейнеры добавляют автоматическую функциональность c

. Для меня Auto-Wiring - это то, что превращает библиотеку в DI-контейнер. Нечто нельзя назвать DI-контейнером, если оно, по крайней мере, не поддерживает Auto-Wiring.