|
Впровадження залежностейВпровадження залежності (англ. Dependency injection, DI) — шаблон проєктування програмного забезпечення, що передбачає надання зовнішньої залежності програмному компоненту, використовуючи «інверсію керування» (англ. Inversion of control, IoC) для розв'язання (отримання) залежностей. Впровадження — це передача залежності (тобто, сервісу) залежному об'єкту (тобто, клієнту). Передавати залежності клієнту замість дозволити клієнту створити сервіс є фундаментальною вимогою до цього шаблону проєктування. Існує три найпоширеніші форми впровадження залежностей:
ОглядВпровадження залежностей — це шаблон проєктування, в якому залежності (або сервіси) впроваджуються, або передаються по посиланню в залежний об'єкт (клієнт) і стають частиною клієнтського стану. Шаблон відокремлює створення залежностей клієнта від власної логіки клієнта, що дозволяє компонентам бути слабко зв'язаними і притримуватися принципів інверсії залежностей і єдиного обов'язку. Це суперечить анти-шаблону service locator, який дозволяє клієнтам знати про систему, що використовується для пошуку залежностей. Переваги
СтруктураUML класи та діаграма послідовності В наведеній вище UML діаграмі класів, клас UML діаграма послідовності демонструє взаємодії часу виконання: Об'єкт ПрикладиБез впровадження залежностейВ наступному C# прикладі, клас // An example without dependency injection
public class Client
{
// Internal reference to the service used by this client
private readonly Service _service;
// Constructor
public Client()
{
// Specify a specific implementation in the constructor instead of using dependency injection
_service = new ServiceExample();
}
// Method within this client that uses the services
public string Greet()
{
return "Hello " + _service.Name;
}
}
Впровадження через конструкторКлас, якому потрібна залежність, повинен надати відкритий конструктор, який приймає екземпляр необхідної залежності як аргумент конструктора. У більшості випадків, це повинен бути тільки public конструктор. Якщо необхідна більш ніж одна залежність, можуть бути використані додаткові аргументи конструктора. Є найбільш широко вживаним і рекомендованим методом впровадження залежностей. public class Client
{
private readonly IService _service;
// Constructor
public Client(IService service)
{
if (service == null)
{
throw new ArgumentNullException("service");
}
_service = service;
}
// Method within this client that uses the services
public string Greet()
{
return "Hello " + _service.Name;
}
}
Впровадження через властивістьКлас, який використовує залежність, повинен надати відкриту, доступну для запису властивість типу залежності. public class Client
{
public IService Dependency {get; set;}
// Method within this client that uses the services
public string Greet()
{
return "Hello " + Dependency.Name;
}
}
Впровадження через методЕлемент, що викликає метод, впроваджує залежність як параметр методу в кожен виклик методу. Впровадження в метод краще використовувати тоді, коли залежність може змінюватися з кожним викликом методу. Це може бути в тому випадку, коли залежність сама по собі представляє значення, або коли елемент, що викликає, надає споживачеві інформацію про контекст, в якому викликається операція. public class Client
{
// Method within this client that uses the services
public string Greet(IService service)
{
if (service == null)
{
throw new ArgumentNullException("service");
}
return "Hello " + service.Name;
}
}
Конфігурування через XMLКонфігурування DI-контейнеру Unity за допомогою XML <register type="IBasketService" mapTo="BasketService" />
<register type="BasketDiscountPolicy" mapTo="RepositoryBasketDiscountPolicy" />
<register type="BasketRepository" mapTo="SqlBasketRepository">
<constructor>
<param name="connString">
<value value="CommerceObjectContext" typeConverter="ConnectionStringConverter" />
</param>
</constructor>
</register>
<register type="DiscountRepository" mapTo="SqlDiscountRepository">
<constructor>
<param name="connString">
<value value="CommerceObjectContext" typeConverter="ConnectionStringConverter" />
</param>
</constructor>
</register>
<register type="ProductRepository" mapTo="SqlProductRepository">
<constructor>
<param name="connString">
<value value="CommerceObjectContext" typeConverter="ConnectionStringConverter" />
</param>
</constructor>
</register>
<register type="CurrencyProvider" mapTo="SqlCurrencyProvider">
<constructor>
<param name="connString">
<value value="CommerceObjectContext" typeConverter="ConnectionStringConverter" />
</param>
</constructor>
</register>
Перетворення інтерфейсу IBasketService в клас BasketService реалізується за допомогою простого елемента register. Деякі конкретні класи приймають рядок з'єднання як вхідні дані, тому необхідно визначити, яким чином знаходиться значення цього рядка. Що стосується Unity, можна зробити це, вказавши, що ви використовуєте користувацький тип конвертера під назвою ConnectionStringConverter. Цей конвертер буде шукати значення CommerceObjectContext серед стандартних рядків з'єднання web.config і повертати рядок з'єднання з цим ім'ям. Решта елементів повторюють ці два патерни. Оскільки Unity може автоматично перетворювати запити в конкретні типи, навіть якщо відсутні явні реєстрації, вам не потрібно застосовувати XML-елементи для HomeController і BasketController. Завантаження конфігурації в контейнер виконується за допомогою виклику єдиного методу:
ПопередженняЯк тільки ваш застосунок(ісп.) буде виростати в розмірах і ускладнюватися, теж саме буде відбуватися і з вашим конфігураційним файлом, якщо ви використовуєте конфігураційну композицію. Він може стати справжньою проблемою, оскільки цей файл моделює такі сутності коду, як класи, параметри тощо, але без переваг компілятора, опцій налагодження і т. д. Файли будуть ставати крихкими і непрозорими з точки зору наявності помилок, тому використовуйте даний підхід тільки, якщо вам необхідно пізнє зв'язування. Конфігурування програми за допомогою коду c.For<IBasketService>().Use<BasketService>();
c.For<BasketDiscountPolicy>().Use<RepositoryBasketDiscountPolicy>();
string connectionString = ConfigurationManager.ConnectionStrings["CommerceObjectContext"].ConnectionString;
c.For<BasketRepository>().Use<SqlBasketRepository>().Ctor<string>().Is(connectionString);
c.For<DiscountRepository>().Use<SqlDiscountRepository>().Ctor<string>().Is(connectionString);
c.For<ProductRepository>().Use<SqlProductRepository>().Ctor<string>().Is(connectionString);
c.For<CurrencyProvider>().Use<SqlCurrencyProvider>().Ctor<string>().Is(connectionString);
Для того щоб підтримати ті класи, для яких потрібен рядок з'єднання, ви продовжуєте послідовність For/Use шляхом виклику методу Ctor та передачі рядка з'єднання. Метод Ctor виконує пошук строкового параметра в конструкторі конкретного класу і використовує передане значення для цього параметра. Використання коду як конфігурації не тільки компактніше XML-конфігурації, але також підтримується компілятором. Типи аргументів являють собою реальні типи, які перевіряє компілятор. Змінна API StructureMap поставляється навіть з деякими видовими обмежувачами, які повідомляють компілятору про перевірку того, чи збігається тип, який визначається методом використання з абстракціями, позначеними за допомогою методу For. Якщо перетворення неможливо, то код не компілюється. Незважаючи на те, що технологія використання коду як конфігурації безпечна і проста в застосуванні, її потрібно більше супроводжувати. Щоразу при додаванні у застосунок нового типу ви також повинні пам'ятати і про його реєстрацію. Див. такожПосилання
|