Стратегія протоколювання виключень

Існують різні варіанти протоколювання даних виключення :

1. Windows Event Log(Журнал реєстрації подій Windows), якщо додаток розгорнутий на одному комп'ютері, якщо необхідно використати існую- чі інструменти для перегляду журналу, або якщо надійність є основною вимогою.

2. SQL Database, якщо додаток розгорнутий на фермі або в кластері, якщо необхідно забезпечити централізоване протоколювання, або якщо пот- рібно гнучкість в структуризації і протоколюванні даних виключення.

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

4. Механізм обміну повідомленнями(Message Queuing) в якості механізму доставки для передачі повідомлень про виключення в точку їх остаточ- ного призначення, якщо надійність є головною вимогою, якщо застосу- вання розгорнуті на фермі або в кластері, або якщо вимагається центра- лізувати протоколювання.

У будь-якому додатку може використовуватися декілька з представлених ва- ріантів залежно від сценарію і політики обробки виключень. Наприклад, ви-

ключення безпеки можуть протоколюватися в Security Event Log, а виклю- чення бізнес-логіки - у базу даних.

Стратегія повідомлення про виключення

У корпоративних додатках необхідно передбачити повідомлення для адмініс- траторів і операторів. Для цього можуть використовуватися такі технології, як події WMI, електронні листи SMTP, текстові повідомлення SMS або інші системи повідомлення.

Якщо вимагається відокремити систему контролю і повідомлення від коду додатків, і залишити в застосуваннях тільки код протоколювання, то можна використати зовнішні механізми повідомлення, таких як системи моніторин- гу журналів або середовища сторонніх виробників, які виявляють в даних журналу умови виникнення помилки і формують відповідні повідомлення.

Ухвалення рішення про необхідність обробки необроблених виключень

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

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

9. Патерни проектування наскрізної функціональності Наскрізна функціональність і принципи проектування

Наскрізна функціональність - це загальна функціональність, яку не можна віднести до конкретного шару або рівня. До наскрізної функціональності від- носять такі операції як аутентифікація, авторизація, кешування, зв'язок, управління виключеннями, протоколювання і валидация.

Наскрізна функціональність(crosscutting concerns), по можливості, повинна реалізовуватися централізовано. Наприклад, є код, котрый виконує ведення " лігв" - протоколювання і цей код реалізований на різних шарах і рівнях.

При зміні вимог треба виконати пошук і зміну коду по усьому застосуванню.

Якби цей код був централізований те внести зміна знадобилася б лише в од- ному місці.

До механізмів реалізації наскрізної функціональності відносять фреймвор- ки, які реалізують шаблони проектування впровадження залежнос- тей(Dependency Injection), а також Аспектно-Ориентированноге Програму- вання(АOP)

Для використання патерну Впровадження залежності(Dependency Injection) застосовують програмні компоненти т.з. DI- кінтейнерами. ( Unity для плат- форми .NET компанії Microsoft; Ninject - open source рішення).

Основне завдання контейнера - надати клієнтові об'єкт, що повністю ініціалі- зував, з усіма залежностями, не обтяжуючи клієнта знаннями про ці залежно- сті.

Для того, щоб контейнер знав, який тип відповідає інтерфейсу, його необхід- но заздалегідь конфігурувати. Більшість DI- кінтейнеров підтримують мож- ливість завдання конфігурації на рівні зовнішніх текстових файлів, що дозво- ляє виключити необхідність перекомпіляції застосування при заміні одного конкретного типу-сервісу. Такий підхід забезпечує високу гнучкість і дозво- ляє створювати застосування, що повною мірою відповідають принципу сла- бкої зв'язаності.

Аспектно-орієнтоване програмування(АОП) ― парадигма програмуван- ня, яка грунтована на ідеї розділення функціональності для поліпшення роз- биття програми на модулі. Основна ідея зводиться до виділення наскрізної функціональності, розкиданої між модулями програми(класами, функціями), в окремі аспекти, які потім можна повторно використати.

• Наскрізна функціональність виноситься в окремий модуль - ас- пект(aspect).

• У цьому модулі за допомогою точок з'єднання(joint - points) визнача- ється, де, в яких місцях, і за яких умов застосовуватиметься ця функціона- льність.

• Клас, який реалізує наскрізну функціональність називають ра- дою(advice).

• Ради можуть прив'язуватися до точок з'єднання або під час компіляції програми, або під час завантаження програми, або під час виконання.

• Різні бібліотеки реалізації АОП надають різні можливості. Приклад реалізації ― AspectJ(Java)

Принципи проектування

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

2. Залежно від фізичного розподілу компонентів і шарів додатку, компо- ненти наскрізної функціональності можуть бути встановлені на декіль- кох фізичних рівнях.

3. Необхідно розглянути можливості впровадження екземплярів компо- нентів наскрізної функціональності в застосування на підставі даних конфігурації. Це дозволить змінювати використовувані в кожній підсис- темі компоненти наскрізної функціональності без необхідності повтор- ної компіляції і розгортання додатку.

4. Щоб скоротити час розробки потрібно досліджувати можливість засто- сування бібліотек компонентів сторонніх виробників, які надають мож- ливість конфігурації компонент.

5. Використання методик аспектно-орієнтованого програмування(AOP), дозволить впровадити наскрізну функціональність в додатках без реалі- зації явних викликів в коді.