Конфігурування додатків і динамічне завантаження в Visual C # (Sharp)

Всі приклади в попередніх розділах демонстрували, як використовувати докладе з конкретними компонентами Ми знали, якого типу екземпляр потрібно було створити, який інтерфейс використовувати і до якого інтерфейсу звертатися У таких випадках розробник має повний контроль, і по завершенню розробки пріленія все збірки акуратно складаються в один охайний пакет

Але методи, які годяться для розробника, не обовязково можуть бути споучнимі для інших Повернемося до прикладу системи для контролю освітлення, розглянутому в розділі 8 Там ми створили модуль ядра, який був ответствеим за включення і виключення освітлення Реалізації окремих кімнат нахілісь в зумовленою збірці з конкретним імям Така архітектура була б непрацездатною із застосуванням бібліотеки стороннього розробника, т к ядро ​​очікує збірку з певним імям Можливо, ви думаєте: Подумшь, проблема Це проблему легко вирішити – потрібно всього лише видалити стару збірку і перейменувати свою збірку на імя старої збірки . Таке рішення було б робочим, але в той же самий час воно створило б численні труднощі з адмініструванням програми Правильним рішенням буде вказати програно, щоб для реалізацій окремих кімнат вона використовувала певну сбоу і певні типи Ця інформація надається програмі в текстовому файлі Файл, який вказує програмі на необхідність виконання опреденной завдання, називається конфігураційним файлом часу виконання

У цій главі особлива увага приділяється двом областям: використанню конфігаціонних файлів додатків і динамічному виконанню коду З цими двома темами повязана тема, скільки динамічно виконуваного коду має бути коігуріруемим, а скільки певним звичайним чином

Питання звернення до класам і створення їх примірників є як філосокім, так і прагматичним Розглянемо архітектуру, показану на рис 85 Тут представлений модульний інтерфейс і реалізація, які були запропоновані в кестве альтернативної архітектури для системи контролю освітлення врозділі 8

На малюнку прямокутники представляє окремі збірки, що містять опреденія інтерфейсів, реалізації та ядро Метою всіх цих збірок є предоста можливість оновлення окремої збірки, без необхідності оновлювати їх все Але на малюнку не показано, що додаток повинен мати можливість обраться до всіх трьох збірок Відсутність однієї з цих збірок буде проблемою, т к програма не зможе працювати

Але проблемою буде не питання звернення до окремих збірок, а питання, як кдая збірка дізнається про існування інших збірок У попередніх розділах було сказано, що для вирішення цього питання слід використовувати фабрику, т к Фабра усуває необхідність прийняття рішення, яку реалізацію використовувати

Подивимося на цю раду з точки зору коду Припустимо, що слід визначити інтерфейсу знаходиться в збірці, яка містить всі визначення інтерфейсів:

public interface IMyInterface { }

Реалізує інтерфейс клас визначається в збірці implementations:

class MyImplementation : IMylnterface { }

Якщо який-небудь клас в іншій збірці хоче використовувати функціональність

My implementation, то створюється наступна фабрика:

public static Factory {

public static IMylnterface Instantiate() { return new MyImplementation()

}

}

Так як клас MyImplementation не оголошений public, ТО клас Factory потрібно визначити в реалізаціях збірки Це передбачає, що використовує функціальность збірка має посилання на реалізації

Використання фабрики є прийнятним і вирішує проблему розвязки, щоб користувачеві реалізації не потрібно було знати про неї У той час як користувачеві не потрібно знати імя реалізації, йому потрібно знати, в якій збірці вона знаходиться Це означає, що при розробці коду необхідно звертатися до відповідної збірці Такий підхід називається архітектурою компонентів вихідного коду, т к виконується розвязка інтерфейсу і реалізації, але встановлюється звязок між збірками

Щоб вирішити проблему, представлену в чолі 8, де ми створили ядро ​​системи управління освітленням, але не знали заздалегідь реалізацій модулів для окремих кімнат, необхідно виконати розвязку компонентів під час виконання проженія Це можна було б зробити за допомогою конфігурації, дозволяючи коні користувачеві підключати (plug in) реалізації для кімнат, контрольовані ядром Розробники називають розвязку часу виконання підключається архектурой  (http://enwikipediaorg/wiki/Plugin),  Ось тут і знаходить застосування комбінація конфігурувати і звичайного коду Угода правіше конфі-

гураціі (Convention over configuration ) є філософією інфраструктури RoR (Ruby on Rails, інфраструктура, призначена для прискорення, спрощення та підвищення ефективності розробки Web-додатків, написана мовою програмування Ruby), що означає, що розробники визначають тільки нтандартние частини своїх додатків

Використання архітектури конфігурування для виконання розвязки

У конфігураційному сценарії часу виконання архітектура, показана на рис 85, не змінюється в ній залишаються визначення, реалізації, ядро ​​і половательскіе збірки Змінюється спосіб створення посилань на індивідуальні кооненти

Для початку розглянемо просту ситуацію У вас є питання, і ви знаєте, хто міг би на нього відповісти Ви знаєте, що у цієї людини є телефон, але ви не знаєте номер цього телефону За аналогією з даної ситуацією, в програмуванні роль телефону відіграє інтерфейс реалізації, а завданням – встановлення звязку з реалізуються Номер телефону можна дізнатися в телефонній книзі, яка містить імена людей, їх адреси і телефонні номери Імена та адреси легко запамятовуються, але телефонні номери піддаються запамятовуванню дещо важче Тому телонний довідник призначений для створення перехресного посилання між легко запоминаемой інформацією і важко запамятовується У програмуванні перрестная посилання надається файлом конфігурації, який асоційований з конкретним додатком NET Отримавши перехресну посилання на інформацію, ми знаємо місцезнаходження збірки і можемо створити екземпляр типу, що вказується перехресної посиланням Таким чином, файл конфігурації надає нам іормацію про місцезнаходження і імені типу

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

Стандартна архітектура намагається спростити конфігурування, засновуючи легко запамятовується шаблон звернення до типу Візьмемо, наприклад, телефонний номер 1-800-BIG-CARS Хоч 1 і 800 – числа, їх легко запамятати, а слова BIG CARS,

1 Поняття угода правіше конфігурації означає, що розробник повинен вказувати тільки нестандартні аспекти програми Наприклад, якщо в моделі є клас Продажі, то соответс таблиця в базі даних за замовчуванням називається продажу Тільки якщо розробник откляется від цієї конвенції, наприклад, називаючи таблицю проданние_товари, то йому потрібно писати код відносно цих імен — Пер

крім того, що вони є словами, які, загалом, легко піддаються заїкання, тут ще несуть і певне смислове навантаження Вживання слів замість цифр в телефонному номері можливо тому, що кожній цифрі на панелі набору телефонного номера співвіднесені три або чотири літери Таким обром, числовий номер, відповідний буквенному BIG-CARS, буде 244-2277

Угоди можуть бути корисними, але тільки якщо ви їх знаєте Наприклад, якщо ви не обізнані в системі телефонних номерів, то будете ламати собі голову, як слова BIG CARS можуть бути телефонним номером, який по ідеї повинен Вира числами Інформація, якою у вас немає, – це угода про те, як буи перетворюються в номер

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

Незалежно від використовуваної архітектури, стандартної або конфігурується, складання будуть завантажуватися динамічно, як демонструється в цьому розділі

Джерело: Гросс К С # 2008: Пер з англ – СПб: БХВ-Петербург, 2009 – 576 е: ил – (Самовчитель)

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*