Аспекти розробки транзакційної бізнес логіки

Анотація

Актуальність. Перед розробниками інформаційних систем часто постає завдан-ня впровадження транзакційної бізнес-логіки. І хоча специфіка обробки транзакцій на рівні СУБД добре відома, питання реалізації транзакцій на рівні програмних компоне-нтів здається відкритим, а рішення про те, як розробити та реалізувати транзакцій-ну бізнес-логіку. залишалася прерогативою розробників. Сьогодні існує кілька можливих практичних реалізацій транзакційної бізнес-логіки: використання шаблону Unit Of Work (UoW) [1, 2]; бібліотеки SystemTransactions [3]; безпосередня реалізація транзакційної логіки за допомогою збережених процедур, що зберігаються в базі даних. Кожен з існуючих варіантів має свої переваги та недолі-ки. Так, приховування бізнес-правил у збережених процедурах значно знижує стійкість системи до змін, а по-друге, щоб зрозуміти реалізацію правил бізнес-логіки, розробник не може покладатися лише на відповідний рівень бізнес-логіки (частина логіки буде знаходитися в шарі бізнес-логіки, а частина у збережених процедурах). Використання шаблону UoW спрощує підтримку системи, збільшує її гнучкість та змогу адаптації до змін, але виконання кожної транзакції вимагає створення окремого UoW з набором залежностей, що може призвести до значних витрат у багатокористувацькій систе-мі. Клас TransactionScope з бібліотеки System.Transactions забезпечує простий спосіб позначити блок коду, який бере участь у транзакції, приховуючи деталі реалізації та максимально полегшуючи визначення транзакції, але є ресурсомістким компонетом зы скритою внутрішньою логікою, тому не може бути оптимальним варіантом для сис-тем, орієнтованих на високу продуктивність.. Проблема. Переваги та недоліки вищезазначених підходів привели нас до ідеї рі-шення, яке було б досить гнучким і пристосованим до потреб розробників програмного забезпечення. Основна частина. Рішення засноване на введенні додаткового компонента Transaction Manager, що відповідає за обробку транзакцій. Цей рівень використову-ється рівнем бізнес-логіки і взаємодіє з рівнем доступу до даних (сховищами) для вико-нання операцій з даними. Його можна розглядати як компонентну надбудову над рів-нем DAL, що відповідає за обробку транзакцій. Рівень обробки транзакцій можна під-ключити не тільки до DAL, а й до шарів служб та утиліт для виконання, наприклад, розподілених транзакцій, якщо це необхідно. Кожна можлива транзакція реалізована як метод цього компонента. Для виконання транзакції цей компонент використовує купу необхідних репозиторіїв. Ці методи можуть служити лише точками доступу (тобто шлюзами) до об’єктів відповідного типу, які, у свою чергу, безпосередньо від-повідають за специфіку транзакцій, що приховують деталі реалізації та пов’язані ре-сурси (наприклад, репозиторії). Оскільки всі запити на реалізацію транзакцій будуть проходити тільки через один об’єкт Transaction Manager, існує очевидна потреба в реалізації асинхронних ме-тодів. В узагальненому варіанті ми можемо розглянути варіант пулу менеджерів транзакцій, який можна використовувати для розподілу навантаження. Іншим питанням є можливість наявності декількох транзакційних менеджерів (тобто горизонтальна декомпозиція менеджера). Справа в тому, що реальні проекти мають сотні таблиць у своїх базах даних і можуть досягати тисячі об'єктів, і біль-шість з них можуть брати участь в транзакціях. Але ситуація, у якій use-case (преце-дент) або навіть група прецедентів використовує для реалізації сотні сутностей тра-пляється рідко. Висновки. В даний час транзакції є дуже потужним механізмом впровадження бізнес-правил і успіх їх використання залежить від підходів, обраних розробником. У цій роботі ми пропануємо підхід із введенням додаткового рівня абстракції, що відповідає за обробку транзакцій, який можна ефективно застосувати, якщо стандартні підходи з якихось причин не підходять.