Контейнери впровадження залежності.

Отже, ми вирішили свою проблему залежності: ми збираємося впроваджувати залежності в конструктори класів під час виконання. Але нам належить вирішити ще одну проблему: як створити екземпляр конкретної реалізації інтерфейсів, не створюючи залежності в інших частинах програми?

Відповідь полягає в контейнері DI, який також називають контейнером IоС. Він являє собою компонент, який діє в якості посередника між залежностями, необхідними такому класу, як PasswordResetHelper, і конкретною реалізацією цих залежностей, наприклад MyEmailSender.

Ми реєструємо в контейнері DI набір інтерфейсів або абстрактних типів, які використовує наш додаток, і вказуємо, примірники яких конкретних класів повинні бути створені для дотримання залежностей. Таким чином, нам доведеться зареєструвати в контейнері інтерфейс IEmailSender і вказати, що примірник MyEmailSender повинен створюватися у всіх випадках, коли потрібно lEmailSender. Завжди, коли нам потрібно IEmailSender, наприклад, для створення екземпляра PasswordResetHelper, ми звертаємося до контейнера DI і отримуємо реалізацію класу, яка була зареєстрована в якості конкретної реалізації інтерфейсу за замовчуванням – у даному випадку MyEmailSender.

Контейнер DI не потрібно створювати самостійно. Доступний ряд прекрасних безкоштовно ліцензованих реалізацій і реалізацій з відкритим вихідним кодом. Ми будем використовувати реалізацію Ninject, подробиці про яку можна з'ясувати на сайті www.ninject.org . Короткий опис її використання буде приведено нижче.

Порада . В Microsoft створили власний контейнер DI під назвою Unity. Але застосування Ninject демонструє можливість змішування і узгодження засобів при використанні MVC. Більш детальну інформацію про Unity можна знайти на сайті unity.codeplex.com .

Роль контейнера DI може здаватися простою і тривіальною, але насправді це не так. Хороший контейнер DI, такий як Ninject, має ряд дуже зручних функціональних можливостей.

• Створення ланцюжка залежностей . У випадку запиту компонента, який має власні залежності (наприклад, параметри конструктора), контейнер задовольнить і ці залежності. Таким чином, якщо конструктор класу MyEmailSender вимагає реалізацію інтерфейсу INetworkTransport, контейнер DI створить екземпляр реалізації за замовчуванням цього інтерфейсу, передасть її конструктору MyEmailSender і поверне результат в якості реалізації за замовчуванням IEmailSender.

• Управління життєвим циклом об'єкта . Якщо компонент запитується більш одного разу, чи потрібно кожного разу отримувати один і той же або зовсім новий екземпляр? Хороший контейнер DI дозволяє конфігурувати життєвий цикл компонента, надаючи можливість вибору з набору заздалегідь визначених варіантів, у тому числі єдиний екземпляр ( один і той же примірник у всіх випадках), тимчасовий примірник ( новий екземпляр в кожному випадку), примірник на потік, примірник на HTTP-запит, примірник з пулу і безліч інших.

• Конфігурування значень параметрів конструктора. Наприклад, якщо реалізація інтерфейсу INetworkTransport вимагає рядковий параметр serverName, у нас повинна бути можливість установки його значення в конфігурації контейнера DI. Це груба, але проста система конфігурування, яка позбавляє код від якої необхідності передавати рядки підключення, адреси серверів і т . п.

Можливо, у вас виникне бажання створити власний контейнер DI. При наявності вільного часу і бажання більше дізнатися про різних гранях C # і . NET рішення цього завдання може стати прекрасним експериментальним проектом. Якщо ви хочете використовувати контейнер DI в робочому додатку MVC, ми рекомендуємо зупинитися на одному з готових контейнерів, такому як Ninject.