Методика реалізації об’єктно-реляційного відображення у середовищі .Net
Стаття присвячена реалізації бібліотеки об’єктно-реляційного відображення для платформи .Net. Робота заснована на патернах
 проектування, і розглядає загальні питання об’єктно-реляційного відображення в контексті особливостей реалізації на конкретній
 платформі .Net та мові програмув...
Збережено в:
| Дата: | 2004 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
Інститут програмних систем НАН України
2004
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/2321 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Методика реалізації об’єктно-реляційного відображення у середовищі .Net / А.Ю. Дорошенко, В.Г. Романенко // Проблеми програмування. — 2004. — N 2,3. — С. 409-416. — Бібліогр.: 14 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860202036321058816 |
|---|---|
| author | Дорошенко, А.Ю. Романенко, В.Г. |
| author_facet | Дорошенко, А.Ю. Романенко, В.Г. |
| citation_txt | Методика реалізації об’єктно-реляційного відображення у середовищі .Net / А.Ю. Дорошенко, В.Г. Романенко // Проблеми програмування. — 2004. — N 2,3. — С. 409-416. — Бібліогр.: 14 назв. — укр. |
| collection | DSpace DC |
| description | Стаття присвячена реалізації бібліотеки об’єктно-реляційного відображення для платформи .Net. Робота заснована на патернах
проектування, і розглядає загальні питання об’єктно-реляційного відображення в контексті особливостей реалізації на конкретній
платформі .Net та мові програмування C#. Актуальність такої роботи пов’язана із тим, що незважаючи на зростаючу популярність .Net,
бібліотек об’єктно-реляційного відображення для неї практично не існує. В рамках цієї роботи була виконана робоча реалізація бібліотеки,
яка була успішно використана для побудови інформаційної системи рекрутингової агенції.
Статья посвящена вопросам реализации библиотеки объектно-реляционного отображения на платформе .Net. Работа основана на
шаблонах проектирования и рассматривает общие вопросы объектно-реляционного отображения в контексте особенностей реализации на
конкретной платформе .Net и языке программирования C#. Актуальность работы связана с тем, что несмотря на растущую популярность
.Net, библиотек объектно-реляционного отображения для нее практически не существует. В рамках этой работы было реализована
работающая реализация библиотеки, которая была успешно использована для построения информационной системы рекрутингового
агентства.
The article touches upon the problem of building object-relational mapping framework for the .Net platform. The work is based on design
templates and is concentrated on implementation details of object-relational techniques in context of .Net platform and C# language. This is actual
because in spite of growing .Net platform popularity very few if any object-relational mapping frameworks for it exists yet. A working
implementation of the framework is produced as a result and successfully used in implementation of Human Resource Management Solution for a
Recruiting agency.
|
| first_indexed | 2025-12-07T18:10:46Z |
| format | Article |
| fulltext |
1
МЕТОДИКА РЕАЛІЗАЦІЇ ОБ’ЄКТНО-РЕЛЯЦІЙНОГО
ВІДОБРАЖЕННЯ У СЕРЕДОВИЩІ .NET
OBJECT-RELATIONAL MAPPING TECHNIQUES FOR .NET FRAMEWORK
Дорошенко А.Ю., Романенко В.Г.
Інститут програмних систем, 03187, Київ, пр. Глушкова, 40, корп. 5, (044) 266-1538, dor@isofts.kiev.ua
Києво-Могилянська Академія, 04070, Київ, вул. Сковороди, 2, (044) 456-5183, VladRomanenko@ukr.net
Стаття присвячена реалізації бібліотеки об’єктно-реляційного відображення для платформи .Net. Робота заснована на патернах
проектування, і розглядає загальні питання об’єктно-реляційного відображення в контексті особливостей реалізації на конкретній
платформі .Net та мові програмування C#. Актуальність такої роботи пов’язана із тим, що незважаючи на зростаючу популярність .Net,
бібліотек об’єктно-реляційного відображення для неї практично не існує. В рамках цієї роботи була виконана робоча реалізація бібліотеки,
яка була успішно використана для побудови інформаційної системи рекрутингової агенції.
Статья посвящена вопросам реализации библиотеки объектно-реляционного отображения на платформе .Net. Работа основана на
шаблонах проектирования и рассматривает общие вопросы объектно-реляционного отображения в контексте особенностей реализации на
конкретной платформе .Net и языке программирования C#. Актуальность работы связана с тем, что несмотря на растущую популярность
.Net, библиотек объектно-реляционного отображения для нее практически не существует. В рамках этой работы было реализована
работающая реализация библиотеки, которая была успешно использована для построения информационной системы рекрутингового
агентства.
The article touches upon the problem of building object-relational mapping framework for the .Net platform. The work is based on design
templates and is concentrated on implementation details of object-relational techniques in context of .Net platform and C# language. This is actual
because in spite of growing .Net platform popularity very few if any object-relational mapping frameworks for it exists yet. A working
implementation of the framework is produced as a result and successfully used in implementation of Human Resource Management Solution for a
Recruiting agency.
Вступ
Необхідність відображення об’єктної моделі системи у реляційну моделлю та навпаки є актуальною для
сучасного процесу розробки прикладних програмних систем. Об’єктно-орієнтовані мови програмування та
середовища, такі як Java, C#, C++ є найбільш розповсюдженим засобом для побудови програмних систем. В той
же час реляційні бази даних є найбільш розвиненим і поширеним способом збереження даних.
Реалізація об’єктно-реляційного відображення не є тривіальною через різні підходи, або парадигми до
моделювання прикладної області. Об’єктна парадигма заснована на принципах розробки програмного
забезпечення, таких як інкапсуляція, зв’язки між об’єктами; в той час як реляційна парадигма заснована на
математичних принципах, зокрема на теорії множин. Різна теоретична база приводить до різних сильних та
слабких місць кожної парадигми. Крім того, об’єктна парадигма націлена на побудову програмної системи з
об’єктів, які мають як дані так і поведінку, в той час як реляційна парадигма націлена на збереження лише
даних. Неспівпадіння у підходах помічається, коли йде мова про переважний метод доступу: в об’єктній
парадигмі навігація між об’єктами виконується через їх зв’язки, а у реляційній парадигмі для встановлення
зв’язків дублюються дані ключових полів у різних таблицях. Ця фундаментальна різниця приводить до далеко
не ідеальної комбінації двох парадигм.
Проблеми реалізації об’єктно-реляційного відображення мають значну історію досліджень, оскільки
об’єктно-орієнтовані мови програмування та реляційні СКБД поширені протягом тривалого часу та часто
використовуються разом. Із розвитком методології шаблонів проектування результати досліджень у галузі
об’єктно-реляційного відображення узагальнювалися та оформлювалися у вигляді бібліотек шаблонів
проектування. Основними об’єктно-орієнтованими мовами та платформами, на яких були реалізовані подібні
бібліотеки є Smalltalk, Java, C++.
Однією з перших робіт в цій галузі була мова патернів Crossing Chasms [CrossingChasms], розроблена для
мови програмування Smalltalk. Значний внесок в розвиток патернів об’єктно-реляційних бібліотек вніс проект
ARCUS (Німеччина) – http://www.objectarchitects.de/arcus/, який був закінчений в 1997 році. Цей проект було
присвячено темі “Software Architectures and Design Patterns in Business Applications” і об’єктно-реляційне
відображення було лише частиною проведених досліджень. Учасники проекту, зокрема Wolfgang Keller
продовжили розвивати його ідеї в подальших роботах, які доступні у вебі за адресою
http://www.objectarchitects.de/ObjectArchitects/orpatterns/ [Keller]. Серед більш пізніх робіт слід відзначити книги
Скота Амблера ”Agile Database Techniques” та Мартіна Фаулера „Patterns of Enterprise Application Architecture”
[Fowler].
Місце об’єктно-реляційного відображення в процесі розробки програмного забезпечення. Більшість
великих інформаційних систем в наш час розробляються за принципом трирівневої чи багаторівневої
архітектури. Вони реалізують рівень представлення для взаємодії з користувачем; рівень бізнес-об’єктів для
моделювання бізнес процесів та рівень даних для тривалого збереження даних.
2
Для реалізації рівня бізнес-об’єктів за допомогою об’єктно-орієнтованої технології, необхідно зв’язати її
із базою даних. Це залежить від типу використаної бази даних. Перелічимо можливі типи баз даних та
технології доступу що відповідають їм:
• Об’єктно-орієнтована база даних
• Об’єктно-реляційний рівень доступу поверх реляційної бази даних
• Рівень безпосереднього доступу до бази даних, який викликається з рівня бізнес-об’єктів
Надалі темою дослідження буде лише об’єктно-реляційний рівень доступу до даних.
Об’єктно-реляційний рівень приховує деталі реалізації бази даних від бізнес-логіки. Він надає
можливості бізнес-об’єктам бути збереженими – здатність читати, писати та видаляти дані з джерела даних. В
ідеалі бізнес-об’єкт не повинен нічого знати про те, яким чином він зберігається.
Реляційна або інша СКБД
Об’єктно-реляційний
рівень доступу
Інтерфейс видів
(View Interface)
Об’єктно-орієнтована мова програмування (C++, Smalltalk, Java, C#)
Реляційний
рівень доступу
Об’єктний рівень
доступу
Об’єктно-
орієнтована СКБД
Мал.. 2. Різні типи рівнів доступу до даних.
Презентаційний рівень
Контроллери (Controllers)
Види (Views)
Рівень бізнес-об’єктів
Бізнес-об’єкти (Business Objects)
Рівень даних
Сервіси збереження даних (Persistence Services)
Мал. 1. Структура багаторівневої архітектури інформаційної системи.
3
Ефективний об’єктно-реляційний рівень надає ряд переваг:
• Він зменшує зв’язування між схемою об’єктів та схемою даних, збільшуючи можливість по
розвитку обох схем.
• Він реалізує весь код, пов’язаний з даними, в одному місці.
• Він полегшує розробку прикладних програм.
• Він дозволяє фокусуватися прикладним програмістам на бізнес-задачах а адміністраторам баз
даних на базі.
• Він надає загальне місце для реалізації бізнес-правил орієнтованих на дані.
• Він дозволяє використати специфічні особливості бази даних, що дає змогу збільшити
продуктивність системи.
Є також потенційні недоліки об’єктно-реляційного рівню:
• Він вимагає інвестувань.
• Часто вони потребують високого рівня відповідності між об’єктами та базою даних.
• Можуть давати занадто мало контролю над доступом до бази даних.
Стратегії реалізації об’єктно-реляційного рівня. Існує чотири базові стратегії реалізації об’єктно-
реляційного рівня [AmblerОшибка! Источник ссылки не найден.]: безпосередній доступ, об’єкти доступу до
даних, бібліотеки доступу до даних (persistence frameworks) та сервіси.
Розглянемо кожну із стратегій реалізації більш детально.
Безпосередній доступ. Базова стратегія безпосереднього доступу полягає у тому, що бізнес-об’єкти
виконують безпосередній доступ до джерела даних, зазвичай надсилаючи SQL-запити до бази даних. На
платформі Java для цього використовується бібліотека класів JDBC (Java Database Connectivity), на платформі
Microsoft – ODBC (Open Database Connectivity), або новіша технологія ADO (ActiveX Data Object). Для
платформи .Net використовується ADO.Net.
Якщо бути точним, то безпосередній доступ не є стратегією об’єктно-реляційного відображення, швидше
це стратегія реалізації доступу за відсутності рівня інкапсуляції об’єктно-реляційного відображення. Але тим не
менш, це коректний спосіб доступу до бази даних. Більш того, схоже що це найбільш уживаний підхід, тому що
він простий і дає програмістам повний контроль над взаємодією їх об’єктів з базою даних. Через свою простоту
це дуже гарний спосіб для використання на початку проекту, коли вимоги доступу до даних прості. Коли ж
вимоги по доступу стають більш складними, кращим вибором буде об’єкти доступу до даних чи бібліотеки
доступу до даних (persistence frameworks).
Об’єкти доступу до даних інкапсулюють від бізнес-об’єктів логіку доступу до бази даних. Типовий
підхід полягає у створенні одного об’єкту доступу до даних для кожного бізнес-об’єкту, наприклад клас
Customer матиме клас Customer_Data. Цей клас реалізує запити SQL для доступу до бази даних, подібно до
стратегії безпосереднього доступу. Головна перевага об’єктів доступу до даних перед безпосереднім доступом
у тому що бізнес-класи не пов’язані безпосередньо з базою даних.
Бібліотеки доступу до даних (Persistence Frameworks), які часто називають рівнями доступу до даних,
повністю інкапсулюють доступ до даних від бізнес-об’єктів. Замість написання коду для реалізації логіки
доступу до даних, треба описати метадані які визначають співвідношення. Таким чином, якщо клас Customer
відповідає таблиці T_Customer, то це буде відображено у метаданих. Метадані описують відповідності всіх
об’єктів джерелу даних, а також асоціації між ними. На основі цих даних бібліотека доступу генерує код для
доступу до бази даних який необхідний для збереження бізнес-об’єктів. В залежності від бібліотеки доступу,
цей код генерується динамічно під час виконання або може бути згенерований статично у формі об’єктів
доступу до даних які компілюються у прикладну систему. Перший підхід дає більшу гнучкість, в той час як
другий дає більшу продуктивність.
Бібліотеки доступу до даних мають різноманітні можливості. Прості підтримують базову
функціональність створення, читання, оновлення та видалення (CRUD – create, read, update, delete) об’єктів а
також базові можливості транзакційного контролю та паралельного доступу. Більш складні можливості
включають складну обробку помилок, пулінг під’єднань до бази даних (database connection pooling), кешування,
підтримку XML, здатність генерувати схему бази даних та опис об’єктно-реляційних відображень (mappings).
Сервіси. У розрізі цього огляду сервіс – це операція, яка надається компонентою, і яка може бути
виконана іншими компонентами. Зараз найбільш популярними архітектурними стратегіями є веб-сервіси, хоча
існує цілий ряж різноманітних стратегій:
• Common Object Request Broker Architecture (CORBA)
• Customer Information Control System (CICS) Transaction
• Distributed Component Object Model (DCOM)
• Electronic data interchange (EDI)
• Jini
• Збережені процедури (Stored procedures)
4
• Веб-сервіси
Сервіси як правило використовуються для інкапсуляції доступу до наслідуваної (legacy)
функціональності та даних, і є чіткий ухил в індустрії будувати нові системи на основі архітектури веб-сервісів
щоб забезпечити повторне використання через інтеграцію систем.
Серед розглянутих стратегій побудови об’єктно-реляційного рівня доступу до даних найбільшу цікавість
представляє стратегія бібліотек доступу до даних.
Особливості реалізації на платформі .Net
При реалізації бібліотеки об’єктно-реляційного відображення необхідно вирішувати цілий ряд питань,
пов’язаних із ефективність, цілісністю даних та зручністю використання бібліотеки кінцевими програмістами.
Вирішення цих питань залежить від платформи, на якій реалізується бібліотека, тож надалі ми сконцентруємо
свою увагу на аспектах реалізації об’єктно-реляційного відображення для платформи .Net.
Основою для проведення даного дослідження стала робота над бібліотекою об’єктно-реляційного
відображення Sisyphus Persistence Framework. Ця вільно розповсюджувана бібліотека була єдиною доступною
бібліотекою з відкритим вихідним кодом на момент початку роботи автором над даною темою. Тому її було
обрано у якості вихідної точки для проведення подальшої роботи. На той час бібліотека мала базові можливості
об’єктно-реляційного відображення, вона дозволяла автоматично зберігати об’єкти в базі а також автоматично
оброблювала відношення один до багатьох. В процесі проведення даної роботи бібліотеку було розширено
автоматичною підтримкою відношень один до одного та багато до багатьох, що зробило її повноцінним
засобом об’єктно-реляційного відображення. Результати роботи опубліковано на сайті проекту Sisyphus
Persistence Framework, з якого доступні для завантаження і вихідні тексти.
Розгляд особливостей реалізації рівня об’єктно-реляційного доступу до даних буде проводитись в розрізі
застосування патернів проектування до конкретної платформи програмування .Net із врахування особливостей
платформи та мови програмування C#. Значна частина досвіду по реалізації об’єктно-реляційного рівня
доступу, що накопичена попередніми дослідниками і узагальнена у вигляді патернів, у універсальною і може
бути безпосередньо застосована до платформи .Net. Це стосується, наприклад, описаних у [Crossing Chasms]
архітектурних патернів: патерн чотирирівневої архітектури і патерн проектування структури бази у часі. Крім
архітектурних патернів є значна кількість патернів, яка стосується більше проектування, аніж реалізації – це так
звані статичні патерни у термінах авторів [Crossing Chasms]. До них відносяться: представлення об’єктів у
вигляді таблиць, ідентифікатори об’єктів, зовнішні посилання (Foreign Key Reference) і представлення колекцій.
Безпосередньо реалізації стосуються так звані динамічні патерни: брокер, метадані, об’єкт запиту. Ряд патернів,
які було застосовано в реалізації бібліотеки, описано в [Yoder, Johnson, Wilson] і в [Ambler].
Перейдемо до детального огляду патернів та особливостей їх реалізації на платформі .Net.
Метадані (Metadata)
Проблема: Базовою задачею збереження об'єктів у базі даних є відображення атрибутів об'єкту на
колонки таблиці у БД. Кожен атрибут відповідає одній або більше колонкам у таблиці, але не всі колонки
мають бути збережені у базі, деякі використовуються лише для тимчасових обчислень.
Рішення: Опис відображення може бути представлений у різних форматах. Розповсюдженим підходом є
представлення метаданих у вигляді XML-файлу, зокрема такий спосіб використовують чимало Java-бібліотек.
Але на платформі .Net більш зручним є використання атрибутів. Це дозволяє описувати метадані безпосередньо
разом із класами, яких вони стосуються.
Приклад:
[SpfTypeStorage(
TableName = "Person",
IdFieldName = "ID",
PersisterType = typeof(SpfDefaultEntityPersister))]
public class Person : SpfEntity
{
[SpfFieldStorage("PersonFirstName")]
[SpfStringDataType()]
public string FirstName;
[SpfFieldStorage("PersonLastName")]
[SpfStringDataType()]
public string LastName;
[SpfInt32DataType()]
public int MaritalStatus;
[SpfDateTimeDataType()]
public DateTime DateOfBirth;
}
5
У наведеному прикладі спеціальні атрибути позначають, якій табличці в базі даних відповідає даних
об’єкт, кожному полю ставиться колонка в табличці, по замовчанню назва колонки співпадає з назвою поля.
Обговорення: Різні підходи до представлення метаданих – з допомогою атрибутів та XML має свої
переваги і недоліки. Використання XML можна вважати більш дослідженим, тому що такий спосіб широко
використовується у Java-бібліотеках. Перевагою XML файлів є можливість генерувати і модифікувати їх за
допомогою спеціальних засобів. Редагування таких файлів вручну досить важке, ще й тому що файли з мета
даними відірвані від об’єктів, які вони описують. З метаданими у вигляді атрибутів зручно працювати, вони
добре інтегруються у середовище .Net, тому цей спосіб є рекомендованим для реалізації. Зчитування інформації
про атрибути виконується під час виконання, для підвищення ефективності слід застосовувати кешування цих
даних.
Конвертація типів даних (Type Conversion)
Проблема: Необхідно мати можливість зберігати в базі значення полів, типи даних яких не мають
безпосереднього відповідника серед типів бази даних.
Умови: Типи даних полів об’єкта не завжди відповідають типам даних колонок в базі даних. Наприклад,
булевські значення можуть бути представлені в базі як символи “T” та “F” або як 0 та 1. Крім стандартних типів
даних .Net, у бізнес-об’єктах можуть використовуватися поля, визначені користувачем; вони також повинні
прозоро оброблятися бібліотекою. Треба забезпечити конвертацію значень без втрат інформації.
Рішення: Для задовольняння цих вимог запропоновано наступний підхід. Для кожного типу даних
реалізується спеціальний клас-конвертор. Базовим абстрактним класом для усіх конвертерів є клас
SpfDataType. Він реалізує таку функціональність:
public class SpfDataType
{
public virtual bool IsValidValue(Object p_Value);
/// перевірка значення на коректність
public virtual string GetErrorMessage(object p_FieldValue);
/// повідомлення про помилку якщо дані некоректні
public bool IsNullable;
/// чи може поле містити значення NULL
public virtual object GetStorageValue(object p_Value);
/// конвертація значення для збереженя у базі даних
public abstract object ConvertValue(object p_Value);
/// конвертація значення для запису в об'єкт
public abstract Type BaseType;
/// повертає базовий тип .Net Framework, який є основою для даного типу
public virtual int StorageLength;
/// довжина даних у базі
public virtual string GetFormattedValue(object p_Value);
/// форматоване строкове значення
}
Обговорення: Конвертори асоціюються з полями об’єктів через атрибути, як показано у прикладі з
попереднього розділу. Для використання власного типу даних із бібліотекою, достатньо визначити клас
нащадка від SpfDataType, перекрити необхідні методи і вказати атрибут до відповідних полів. Конвертери для
вбудованих типів даних .Net Framework входять в склад бібліотеки.
Механізм збереження (Persistence Mechanism)
Проблема: Об’єктно-реляційний рівень повинен бути незалежним від конкретної бази даних.
Умови: Для доступу до баз даних на платформі .Net використовується бібліотека ADO.Net. Нижче на
малюнку зображено загальну архітектуру ADO.Net.
6
Мал. 3. Архітектура бібліотеки доступу до даних ADO.Net.
ADO.Net є базовою технологією доступу до даних для платформи .Net, яка використовується іншими,
більш високорівневими засобами доступу до даних. ADO.Net є еволюційним продовженням ADO, із значно
переробленою архітектурою. Традиційно обробка даних була заснована на під’єднанні до бази даних, і
представляла собою дворівневу архітектуру. Але в наш час обробка даних все більше будується на
багаторівневих архітектурах, де використовується підхід без постійного під’єднання до бази даних, який краще
маштабується.
Компоненти ADO.Net спроектовані таким чином, щоб відділити доступ до даних від маніпуляцій із
даними. Два центральні компоненти ADO.Net виконують це завдання: клас DataSet та провайдер даних, який
являє собою набір компонентів, що включають об’єкти Connection, Command, DataReader та DataAdapter.
Клас DataSet є центральним компонентом для від’єднаної (disconnected) архітектури ADO.Net. Цей клас
спроектовано для доступу до даних незалежно від джерела даних. В результаті він може бути використаний
багатьма різними джерелами даних, з XML-файлами, або для роботи з локальними даними програми. DataSet
містить колекцію з одного або більше об’єктів DataTable, які складаються з рядків та колонок із даними, а
також первинних ключів, зовнішніх ключів, обмежень (constraint), та інформації про зв’язки між даними.
Іншим базовим компонентом архітектури ADO.Net є провайдер даних .Net, компоненти якого
спроектовані для маніпуляцій з даними та швидкого доступу до даних для читання. Об’єкт Connection
представляє під’єднання до джерела даних. Об’єкт Command надає доступ до команд бази даних для читання
даних, модифікації та запуску збережених процедур. DataReader представляє високопродуктивний потік
даних з джерела даних. І нарешті DataAdapter є мостом між об’єктом DataSet та джерелом даних. Він
використовує об’єкти Command для виконання SQL-запитів до джерела даних як для завантаження даних у
DataSet, так і для повернення змін у даних назад у джерело даних. Провайдери даних утворюють ієрархію
залежних від бази даних класів, що перешкоджає переносимості бібліотеки доступу до даних.
Рішення: Для абстракції бібліотеки від конкретної реалізації провайдерів даних для різних баз,
запропоновано інтерфейс IDataStore. Він містить набір функцій, що утворюють незалежну від бази даних
обгортку навколо відповідного провайдера даних ADO.Net.
public interface ISpfDataStore
{
IDbConnection GetConnection();
/// реалізація класу під’єднання до бази даних
string GetParameterText(string p_ParameterName);
/// повертає залежний від бази даних текст параметру запиту
IDbCommand GetCommand(string p_CommandText);
/// повертає реалізацію команди бази даних для конкретного запиту
IDataAdapter GetDataAdapter(IDbCommand p_QueryCommand);
/// повертає реалізацію адаптеру даних для конкретного запиту
void AddCommandParameter(IDbCommand p_Command, string p_Name, object p_Value);
/// додає параметр до команди
}
Обговорення: Конкретні реалізації інтерфейсу ISpfDataStore для різних баз даних можуть бути
підключень до системи за необхідністю, що дає змогу уникати необхідності розповсюджувати не
використовувані бібліотеки.
7
Брокер (Broker)
Проблема: Бізнес-об’єкти повинні бути абстраговані від операцій з базою даних.
Умови: Брокер повинен бути здатним читати і писати об’єкти в базу даних. Він повинен знати формат
кожного об’єкту та вміти генерувати SQL-запити для них.
Рішення: Реалізація класу брокера описується інтерфейсом ISpfEntityPersister.
public interface ISpfEntityPersister
{
SpfEntity Retrieve(object p_AppContext, Type p_EntityType,
object p_EntityId, int p_MaxDepth);
/// Читає об’єкт заданого типу по його ідентифікатору
SpfEntity[] RetrieveMatches(object p_AppContext,
SpfEntityCriteria p_Criteria, int p_MaxDepth);
/// Читає список об’єктів, що відповідають заданому критерію
SpfEntity Persist(object p_AppContext, SpfEntity p_Entity);
/// Зберігає об’єкт у базі даних
void Delete(object p_AppContext, SpfEntity p_Entity);
/// Видаляє з бази даних об’єкт або набір об’єктів за критерієм
}
Обговорення: В рамках бібліотеки Sisyphus реалізоване гнучке рішення, яке дозволяє присвоїти
кожному класу окремий механізм збереження себе у базу. Це дає змогу створювати оптимізовані реалізації
роботи з базою даних. По замовчанню усім об’єктам присвоюється реалізація SpfDefaultEntityPersister,
яка генерує SQL-запити відповідно до структури кожного об’єкта. Створено також дослідницьку реалізацію
брокера, що використовує збережені процедури сервера (stored procedures) для виконання запитів до бази
даних, що дає змогу отримати значний виграш у продуктивності.
Збережені об’єкти (Persistent Object)
Проблема: Бізнес-об’єкти повинні надавати допоміжні функції бібліотеці об’єктно-реляційного доступу.
Умови: При збереженні бізнес-об’єкта до бази треба відслідковувати, створено цей об’єкт заново чи він
вже існує в базі. Кожен об’єкт повинен однозначно ідентифікуватися і співставлятися зі своїм представленням в
базі даних.
Рішення: Реалізація допоміжних функцій виноситься в об’єкт SpfEntity. Цей об’єкт є базовим, від
якого мають наслідуватися усі бізнес-об’єкти, з якими працюватиме бібліотека.
public abstract class SpfEntity
{
public object Id { get {}; }
/// Ідентифікатор об’єкту
public bool GetIsNew();
/// Вказує на те, що об’єкт створений і не існує в базі
public bool GetIsDirty();
/// Вказує на те, що об’єкт змінив своє значення
/// і має бути синхронізований з базою
public override string ToString();
/// Повертає строкове представлення об’єкту
}
Обговорення: Для реалізації бізнес-об’єктів, що працюють з об’єктно-реляційним рівнем, достатньо
лише наслідувати їх від базового класу. За допомогою метаданих можна змінити різноманітні параметри
обробки об’єкта бібліотекою, від стратегії збереження різних полів у базі до механізму взаємодії з базою
взагалі. Як було показано у описі патерну метаданих, для кожного об’єкту описується інформація щодо його
збереження в базі. Наприклад: [SpfTypeStorage(TableName = "Person", IdFieldName = "ID",
PersisterType = typeof(SpfDefaultEntityPersister))]. Останнім параметром PersisterType
описано тип брокера, що буде застосовуватися до даного бізнес-об’єкту.
У вищенаведеному інтерфейсі об’єкт містить інформацію про свій ідентифікатор та стан об’єкту. У
майбутньому до цих атрибутів може бути додано інші поля, наприклад для підтримки віртуальних проксі та
інші необхідні для розширення функціональності бібліотеки.
Об’єкти запиту (Query Object)
Проблема: Крім маніпуляцій з окремими бізнес-об’єктами, необхідно також організовувати складні
маніпуляції із колекціями об’єктів.
Умови: Бібліотека повинна представляти можливості виконання складних запитів не порушуючи
абстрагування бізнес-об’єктів від сховища даних.
Рішення: Реалізація складних запитів представляється ієрархією об’єктів наслідуваних від
SpfEntityCriteria.
8
public abstract class SpfEntityCriteria
{
public readonly Type EntityType;
/// Тип отримуваних об’єктів
public string CommandText;
/// Строка запиту
public string OrderByClause;
/// Порядок сортування результатів
public object[] ParamValues;
/// Параметри запиту
}
Обговорення: Базовий об’єкт критерію містить атрибути, які використовуються брокером для побудови
і виконання складних SQL-запитів. Користувач може створювати наслідувані об’єкти для побудови критеріїв
будь-якої складності із довільним числом параметрів.
Висновки
Платформа .Net є сучасною платформою із розвиненими засобами доступу до даних та високорівневими
мовами програмування. Це дає змогу швидко і ефективно будувати на її основі інформаційні системи масштабу
підприємства. Для таких великих систем найбільш вдалою є багаторівнева архітектура, при якій доступ до
даних абстрагований від бізнес-об’єктів. Об’єктно-реляційний рівень є необхідною складовою таких систем.
Реалізацій бібліотек об’єктно-реляційного відображення існує мало, як вільно доступних так і комерційних, що
є ознакою молодості платформи .Net. На відміну від неї для Java існує дуже велика кількість подібних
бібліотек, різних за можливостями та архітектурою. Тому дослідження особливостей реалізації бібліотеки
об’єктно-реляційного відображення для платформи .Net є досить актуальним питанням.
У цій роботі було зроблено спробу виконати конкретну реалізацію на основі шаблонів проектування, що
виражають досвід попередніх дослідників у цій галузі. За основу роботи була взята вільно доступна бібліотека
Sisyphus Persistence Framework, яка мала базові можливості об’єктно-реляційного відображення. Вона була
розширена до повнофункціональної бібліотеки. Результати роботи доступні на сайті проекту за адресою
http://sisyphuspf.sourceforge.net/.
Реалізація була успішно випробувана в реалізації проекту інформаційної системи рекрутингової агенції.
Застосування бібліотеки для розробки такої системи дозволило значно спростити і пришвидшити роботу. А
результати тестового випробування свідчать про функціональну цілісність виконаної реалізації. Проте для
застосування бібліотеки для побудови більших систем критичними стають питання продуктивності, тому для
майбутнього дослідження перспективними є питання реалізації патернів, пов’язаних із оптимізацією
продуктивності, таких як: кешування, пізнє завантаження (lazy loading), віртуальні проксі (virtual proxy) тощо.
Онлайн-версія інформаційної системи рекрутингової агенції доступна за адресою http://efiles.itcs.com.ua/.
9
Література
1. Scott W. Ambler, Agile Database Techniques: Effective Strategies for the Agile Software Developer. – John Wiley & Sons, 2003.
(http://www.agiledata.org/)
2. Крег Ларман, Применение UML и шаблонов проектирования. 2-е изд. – М.: Вильямс, 2002.
3. Kyle Brown and Bruce Whitenack, "Crossing Chasms: The Static Patterns", in Pattern Languages of Program Design Vol. II, Jim Coplien,
Douglas Schmidt and Norman Kerth, Editors. Addison-Wesley, 1996. (http://www.ksc.com/article5.htm)
4. Martin Fowler et al.: Patterns of Enterprise Application Architecture. Addison Wesley Professional; 1st edition, 2002.
5. Sisyphus Persistence Framework Tutorial. http://sisyphuspf.sourceforge.net/
6. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес, Приемы объектно-ориентированного проектирования. Паттерны проектирования. –
Питер; Серия: Библиотека программиста, 2001.
7. Mark L. Fussell, Foundations of Object-Relational Mapping, 1997. – http://chimu.com/publications/objectRelational/index.html
8. Wolfgang Keller, Mapping Object to Tables. A Pattern Language. – Project ARCUS, 1997.
9. Wolfgang Keller, Jens Coldewey, Relational Database Access Layers. A Pattern Language. The Key Patterns. – Project ARCUS, 1996.
10. Wolfgang Keller, Persistence Options for Object-Oriented Programs. – ObjectArchitects, 2004.
11. Wolfgang Keller, Object/Relational Access Layers. A Roadmap, Missing Links and More Patterns. – ObjectArchitects, 2004.
12. К. Дж. Дейт, Введение в системы баз данных, 6-е издание. – Вильямс, 2000.
13. ADO.NET Architecture, MSDN Library.
14. Designing Data Tier Components and Passing Data Through Tiers, MSDN Library. – August 2002.
|
| id | nasplib_isofts_kiev_ua-123456789-2321 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T18:10:46Z |
| publishDate | 2004 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Дорошенко, А.Ю. Романенко, В.Г. 2008-09-17T14:10:30Z 2008-09-17T14:10:30Z 2004 Методика реалізації об’єктно-реляційного відображення у середовищі .Net / А.Ю. Дорошенко, В.Г. Романенко // Проблеми програмування. — 2004. — N 2,3. — С. 409-416. — Бібліогр.: 14 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/2321 681.3 Стаття присвячена реалізації бібліотеки об’єктно-реляційного відображення для платформи .Net. Робота заснована на патернах
 проектування, і розглядає загальні питання об’єктно-реляційного відображення в контексті особливостей реалізації на конкретній
 платформі .Net та мові програмування C#. Актуальність такої роботи пов’язана із тим, що незважаючи на зростаючу популярність .Net,
 бібліотек об’єктно-реляційного відображення для неї практично не існує. В рамках цієї роботи була виконана робоча реалізація бібліотеки,
 яка була успішно використана для побудови інформаційної системи рекрутингової агенції. Статья посвящена вопросам реализации библиотеки объектно-реляционного отображения на платформе .Net. Работа основана на
 шаблонах проектирования и рассматривает общие вопросы объектно-реляционного отображения в контексте особенностей реализации на
 конкретной платформе .Net и языке программирования C#. Актуальность работы связана с тем, что несмотря на растущую популярность
 .Net, библиотек объектно-реляционного отображения для нее практически не существует. В рамках этой работы было реализована
 работающая реализация библиотеки, которая была успешно использована для построения информационной системы рекрутингового
 агентства. The article touches upon the problem of building object-relational mapping framework for the .Net platform. The work is based on design
 templates and is concentrated on implementation details of object-relational techniques in context of .Net platform and C# language. This is actual
 because in spite of growing .Net platform popularity very few if any object-relational mapping frameworks for it exists yet. A working
 implementation of the framework is produced as a result and successfully used in implementation of Human Resource Management Solution for a
 Recruiting agency. uk Інститут програмних систем НАН України Информационные системы Методика реалізації об’єктно-реляційного відображення у середовищі .Net Object-Relational Mapping Techniques for .Net Framework Article published earlier |
| spellingShingle | Методика реалізації об’єктно-реляційного відображення у середовищі .Net Дорошенко, А.Ю. Романенко, В.Г. Информационные системы |
| title | Методика реалізації об’єктно-реляційного відображення у середовищі .Net |
| title_alt | Object-Relational Mapping Techniques for .Net Framework |
| title_full | Методика реалізації об’єктно-реляційного відображення у середовищі .Net |
| title_fullStr | Методика реалізації об’єктно-реляційного відображення у середовищі .Net |
| title_full_unstemmed | Методика реалізації об’єктно-реляційного відображення у середовищі .Net |
| title_short | Методика реалізації об’єктно-реляційного відображення у середовищі .Net |
| title_sort | методика реалізації об’єктно-реляційного відображення у середовищі .net |
| topic | Информационные системы |
| topic_facet | Информационные системы |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/2321 |
| work_keys_str_mv | AT dorošenkoaû metodikarealízacííobêktnorelâcíinogovídobražennâuseredoviŝínet AT romanenkovg metodikarealízacííobêktnorelâcíinogovídobražennâuseredoviŝínet AT dorošenkoaû objectrelationalmappingtechniquesfornetframework AT romanenkovg objectrelationalmappingtechniquesfornetframework |