АрАрхітектура ADO.NET

Оскільки ADO.NET є набором класів для організації взаємодії клієнтського застосування з базою даних, розгледимо об'єктну модель ADO.NET

На рис......показані класи, складові об'єктної моделі ADO.NET

Рис..... Ієрархія об'єктів ADO.NET

Об'єкти, розташовані в лівій частці, називаються приєднаними і необхідні для управління з'єднанням, транзакціями, вибіркою даних і передачею змін даних в БД. Вони безпосередньо взаємодіють з базою даних.

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

Одній з основних ідей, лежачих в основі ADO.NET, є наявність постачальників даних.

Постачальник даних - це набір класів, призначених для взаємодії з сховищем даних певного типа. За рахунок цього модель ADO.NET є надзвичайно гнучкою і розширюваною. Розгледимо рівні моделі постачальників ADO.NET.

Додаток.NET взаємодіє з базою даних за допомогою постачальників даних. Кожен постачальник даних може забезпечувати доступ тільки до бази даних певного формату. Так, для доступу до БД Microsoft SQL Server використовується постачальник SQL Server для.NET, для доступу до БД Oracle - постачальник Oracle для.NET і так далі Названі бази даних є одними з найпоширеніших у всьому світі, тому постачальники даних для них виділені в окремі елементи моделі ADO.NET; проте існує безліч баз даних іншого формату, до яких необхідно здійснювати доступ з додатка.NET. Для цього можуть застосовуватися постачальники даних OleDb для.NET або ODBC для.NET, що забезпечують доступ до будь-яких даних, для яких існує драйвер OleDb або ODBC відповідно.

При побудові додатка, що використовує доступ до даних, необхідно спочатку спробувати знайти " рідного" постачальника даних.NET Коли ж такого не існує, можна скористатися OleDb, якщо існує відповідний драйвер для джерела даних, до якого встановлюється підключення. Так як. технологія OleDb існує достатньо давно, створено багато драйверів для різних джерел даних, що підтримують її. Якщо в системі не встановлений відповідний драйвер OleDb, його можна спробувати знайти на сайті розробника тієї бази даних, до якої здійснюється доступ, або на сайті Microsoft.

Те ж саме справедливо і для технології ODBC. У ряді випадків існує декілька альтернативних варіантів організації доступу до даних певного формату. Наприклад, доступ до джерела даних на основі SQL Server можна організувати використовуючи або постачальник SQL Server для.NET, або постачальник OleDb. Проте завжди переважно використовувати той постачальник даних, який спеціально призначений для забезпечення доступу до конкретного джерела даних, оскільки він враховує його особливості.

Кожен постачальник.NET реалізує однакові базові класи - Connection, Transaction, DataAdapter, Command, Parameter, DataReader імена яких залежать від постачальника. Наприклад, у постачальника SQL Server існує об'єкт SqlDataAdapter, у постачальника OleDb — OleDbDataAdapter і так далі

У кожного постачальника даних існує власний простір імен. Хоча всі постачальники відносяться до простору імен System.Data, кожен з них містить свій підрозділ цього простору, який містить об'єкти, специфічні для даного постачальника. Наприклад, об'єкт SqlDataAdapter знаходиться в просторі імен System.Data.SqlClient.

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

Розгледимо їх детальніше об’єкти доступу до даних.

Об'єкт Connection - представляє з'єднання з джерелом даних. З його допомогою можна задати типа джерела даних, його місцезнаходження, параметри доступу і ряд інших атрибутів. Перш ніж почати взаємодію з джерелом даних, необхідно встановити підключення до нього за допомогою об'єкту Connection.

Об'єкт Command - представляє запит до джерела даних, виклик процедури, що зберігається, або прямий запит на повернення вмісту конкретної таблиці. Як відомо, існує декілька типів запитів. Частку з них повертають дані, витягувані з джерела даних, інші змінюють записи, треті, - управляють структурою БД. За допомогою об'єкту Command можливо виконати будь-який з перерахованих типів запитів. Відмінності в поведінці об'єкту Command починають виявлятися тоді, коли необхідно виконати той або інший запит. Так, наприклад, при необхідності виконання запиту, що не повертає запису, необхідно використовувати метод ExecuteNonQuery об'єкту Command, а при витяганні даних з БД - метод ExecuteReader, який, у свою чергу, повертає об'єкт DataReader, що дозволяє проглядати отримані в результаті запиту записи.

Об'єкт DataReader призначений для максимально швидкої вибірки і проглядання записів, що повертаються запитом. Проте він дозволяє проглядати весь результуючий набір записів шляхом переміщення від одного запису до іншої і, таким чином, проглядати тільки одну запис за раз. Крім того, DataReader не має можливості для оновлення значень записів і тому може працювати в режимі " тільки для читання", за рахунок чого володіє високою продуктивністю.

Об'єкт Transaction дозволяє здійснювати угрупування записів в логічну одиницю роботи, званою транзакцією. Транзакція логічно об'єднує декілька різних дій, пов'язаних з маніпулюванням даними, в єдине ціле. В процесі виконання дій, здійснюваних в рамках транзакції, СУБД зазвичай кэширует зміни, що вносяться цими діями в дані до моменту завершення транзакції. Це дозволяє проводити відміну будь-яких змін, виконаних в рамках транзакції, у випадку, якщо хоч би одна з дій транзакції завершилася невдало.

Об'єкт Parameter дозволяє вводити в запит елемент, значення якого може бути задане безпосередньо перед виконання запиту. За рахунок цього відпадає необхідність кожного разу змінювати текст самого запиту.

Об'єктом DataAdapter є сполучна ланка між від'єднаними об'єктами ADO.NET і базою даних. З його допомогою здійснюється заповнення таких об'єктів, як DataSet або DataTable, значеннями, отриманими в результаті виконання запиту до бази даних, для подальшої автономної роботи з ними. Окрім цього DataAdapter реалізує ефективний механізм виконання оновлення даних, що зберігаються в базі даних, змінами, внесеними до даних об'єктів DataSet і DataTable.

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

Об'єктом DataColumn є стовпець об'єкту DataTable. Набор же всіх стовпів об'єкту DataTable є колекцією Columns. За допомогою цього об'єкту можна дістати доступ до значення осередку відповідного стовпця.

Об'єкт DataRow є рядком об'єкту DataTable. Набор всіх рядків цього об'єкту є колекцією Rows. DataRow дуже часто використовується для доступу до значення конкретного поля певного запису. При цьому застосовується властивість Item.

Об'єктом DataSet є від'єднаний набір даних, який може розглядуватися як контейнер для об'єктів DataTable. DataSet дозволяє організовувати усередині себе структуру, повністю відповідну реальній структурі таблиць і зв'язків між ними в БД. Це зручно у тому випадку, коли при роботі з базою даних необхідні дані з різних таблиць. В цьому випадку замість того, щоб багато разів звертатися до сервера і вибирати дані з однієї таблиці за раз, можна помістити всі дані в об'єкт DataSet, а потім передати його клієнтському застосуванню. DataSet є дуже потужним інструментом для роботи з від'єднаними наборами даних. Всі зміни, які вносяться до даних, що зберігаються в DataSet кэшируются в об'єктах DataRow. Коли виникає необхідність передачі змін з DataSet в БД, можливо здійснити передачу тільки змінених даних, замість того щоб передавати всі дані об'єкту, і це значно знижує об'єм даних, що передаються між клієнтським комп'ютером і сервером.

Об'єктом DataRelation є опис зв'язків між таблицями реляційної бази даних. Він надається об'єктом DataSet і дозволяє організовувати взаємозв'язку між таблицями від'єднаного набору даних об'єкту DataSet. Об'єкт DataRelation виконує функцію, аналогічну тій, яку виконують зв'язки, визначувані в СУБД між таблицями при створенні структур даних. Це стосується і дотримання принципів посилальної цілісності інформації. Наприклад, DataRelation можна набудувати так, щоб зміни значення первинного ключа батьківської таблиці автоматично передавалися (каскадували) дочерним записам, а при видаленні запису в батьківській таблиці автоматично віддалялися записи в дочірніх таблицях, пов'язаних з нею.

Об'єкт DataView призначений для організації можливості проглядання вмісту DataTable різними способами. Це відноситься до таких операцій, як сортування і фільтрація записів. За допомогою DataView допускається проглядати вміст одного об'єкту DataTable з різними установками фільтрації і сортування. Для цього необхідно використовувати два різні об'єкти DataView, пов'язаних з одним об'єктом DataTable. Така можливість виключає необхідність зберігання одного набору даних в двох різних структурах.