ІТ-інфраструктура для вашого підприємства
Як тільки ми починаємо заглиблюватися в якусь нову технологію, ми забуваємо, як вона розвивалася і що раціонального за нею стоїть. Простеживши розвиток технологій баз даних від ODBC до ADO.NET, простіше вибрати відповідну технологію і оптимізувати її для своїх цілей.
У більшості систем проектування баз даних програми ґрунтуються на одному типі баз даних. У таких простих схемах розробник програми може програмувати безпосередньо, використовуючи системний інтерфейс бази даних. Хоча подібний підхід забезпечує швидкий і ефективний доступ до даних, можуть виникати проблеми, коли завдання розширюється, і розробнику доводиться допрацьовувати програму. При цьому підході це означає, що кожна готова програма повинна мати різні версії з підтримкою різних типів баз даних. Якщо компанії розширюються або об'єднуються одна з одною, додаток повинен отримати доступ до баз даних, заснованим на різних платформах.
Технологія ODBC забезпечує загальний інтерфейс для доступу до різнорідних баз даних стандарту SQL. ODBC використовує мову SQL як стандарт для доступу до даних. На рисунку 1 показана архітектура ODBC. Цей інтерфейс дуже зручний: один додаток може звертатися до різних баз даних SQL через загальний набір команд. Таким чином, розробник може створювати і поширювати додатки, не прив'язуючись до конкретної бази даних.
Малюнок 1. Архітектура ODBC.
Можна також додати драйвер бази даних, щоб додаток могло працювати з базою даних по вибору користувача. Як показано на рисунку 1, менеджер драйверів є проміжною ланкою між додатком і базами даних. Інтерфейс ODBC містить набір функцій, який керує кожним інструментом бази даних. Якщо з додатком потрібно змінити використовувану базу, розробник просто замінює один драйвер іншим, і додаток може працювати як зазвичай, без необхідності модифікації коду програми.
Малюнок 2. Використання DAO для доступу до бази даних.
ODBC використовує низькорівневий інтерфейс, тому програмісти на С і С ++ реально задіюють всі переваги технології ODBC. Програмісти на Visual Basic (VB) не мають простого доступу до інтерфейсу ODBC. До появи VB 6.0 розробники застосовували високорівнева доступ до даних. На рисунку 2 показано, як програмісти VB використовують технологію Data Access Object (DAO) для доступу до даних.
Малюнок 3. Використання RDO для доступу до бази даних.
DAO базується на технології баз даних Microsoft Jet - процесорі баз даних, призначеному для Microsoft Access. JET був першим об'єктно-орієнтованим інтерфейсом для зв'язку з Access. Програми, що використовують Access, можуть задіяти DAO для прямого доступу до даних. Оскільки DAO створювалася відразу ж слідом за Access, застосування цієї технології - найшвидший і найефективніший спосіб доступу до баз даних Access. DAO може працювати і з відмінними від Access базами даних, такими, як SQL Server і Oracle. DAO використовує ODBC, але, оскільки метод DAO спроектований спеціально для взаємодії з JET, JET транслює запити між DAO і ODBC. Цей додатковий крок трансляції та є причиною уповільнення роботи з базами даних, відмінними від Access.
Малюнок 4. Архітектура ODBCDirect.
Щоб подолати це обмеження, розробники Microsoft створили RDO. На рисунку 3 показано, що RDO звертається до ODBС API безпосередньо, минаючи JET. Потім було введено ODBCDirect, розширення DAO, яке відсуває RDO на задній план. На рисунку 4 показано, як DAO-додаток, використовуючи ODBCDirect, звертається до бази даних, минаючи проблеми, які викликає JET.
Через кілька років ODBC стає стандартом для клієнт-серверного доступу до баз даних. ODBC забезпечує стандартний інтерфейс, який вимагає функцій SQL і оптимізований під методи SQL. Однак що станеться, якщо потрібно буде звернутися до нереляційних базі даних, в якій не використовуються принципи SQL (наприклад, Microsoft Exchange Server, сховище якого не містить дані реляційно).
Малюнок 5. Компоненти OLE DB.
Ймовірно, для більшої плутанини розробники Microsoft ввели ще одну об'єктну модель доступу до даних: ADO. ADO працює з об'єктами DAO і RDO, а також підтримує більш прості моделі, ніж DAO і RDO (хоча з надлишковою функціональністю, так що можна виконати операцію декількома способами). Об'єктна ієрархія в ADO більш однорідна, ніж в DAO. ADO містить кілька вбудованих об'єктів, які спрощують доступ до даних з інформаційних сховищ.
На рисунку 6 показано кілька способів, за допомогою яких додаток зв'язується з базою даних. Наприклад, VB-програміст може використовувати ADO для з'єднання додатки з провайдером OLE DB. Якщо база даних не підтримує OLE DB, додаток може задіяти ODBC. Програміст на Visual C ++ може застосовувати ADO або з'єднуватися безпосередньо через OLE DB.
Малюнок 6. Різниця маршрутів додатків в ADO.
Приклад в ADO
Розглянемо простий приклад роботи ADO. У лістингу 1 показано, як можна використовувати типовий об'єкт - набір рядків (Recordset) - центральний об'єкт в ADO. Об'єкт Recordset представляє собою набір записів (таблицю) і підтримує типи курсорів adOpenForwardOnly, adOpenKeyset, adOpenDynamic і adOpenStatic. Курсор може бути як на стороні сервера (за замовчуванням), так і на стороні клієнта.
Для доступу до запису ADO потрібно просканувати набір рядків послідовно. Для доступу до декількох таблиць необхідно виконати запит на об'єднання JOIN, щоб отримати результат у вигляді набору рядків. Хоча об'єкт Recordset підтримує доступ до даних без з'єднання з ними, ADO спочатку був спроектований для даних, з якими встановлено з'єднання. Такий метод доступу змушує зберігати важливі ресурси на стороні сервера. До того ж для передачі набору рядків слід використовувати метод упорядкування, названий COM marshalling. COM marshalling - це процес перетворення типів даних, який, природно, займає корисні ресурси системи.
У пошуках механізму доступу до непов'язаним даними Microsoft розширює ADO і вводить службу Remote Data Services (RDS). RDS створена після ADO і дозволяє передачу об'єкта Recordset клієнту (наприклад, в Web-браузер) при відсутності активного з'єднання. Однак RDS, як і ADO, використовує упорядкування COM marshaling для передачі набору рядків від сервера клієнту.
Коли Microsoft почала розробляти .NET Framework, вона мала добру нагоду переглянути модель доступу до даних. Вирішивши не продовжувати розробку технології ADO, фахівці Microsoft приступили до створення нової структури доступу до даних, при цьому зберігши акронім. Microsoft розробляє ADO.NET на базі вже зарекомендувала себе об'єктної технології ADO. Але ADO.NET орієнтується на три важливі можливості, які не підтримуються ADO: підтримка моделі доступу до непов'язаним даними, що є ключовим елементом для роботи в Web; підтримка тісної інтеграції з XML; інтеграція з .NET Framework (наприклад, сумісність з базовою бібліотекою класів типової системи).
Архітектура ADO.NET. На рисунку 7 представлена архітектура ADO.NET. Об'єкт Recordset, який виконує так багато функцій в ADO, тут відсутня. Замість нього в ADO.NET передбачено кілька особливих об'єктів, що виконують специфічні завдання. В Таблиці 1 описані три з них: DataAdapter, DataReader і DataSet.
Малюнок 7. Архітектура ADO.NET.
Постачальники даних .NET. Дуже важливий компонент ADO.NET, провайдер даних .NET, реалізує інтерфейси ADO.NET. Зокрема, він реалізує об'єкт DataReader так, що його можуть використовувати і додаток, і об'єкт DataSet.
Постачальник даних .NET складається з чотирьох основних компонентів: Connection - для зв'язку з джерелом даних; Command виконує команди над джерелом даних; DataReader читає дані з джерела даних в однобічному режимі «тільки читання», і DataAdapter, який читає дані з джерела даних і використовує їх для заповнення об'єкта DataSet.
Visual Studio .NET містить два постачальника даних .NET. Постачальник даних SQL Server .NET забезпечує зв'язок з SQL Server 7.0 і пізнішими версіями. Цей метод доступу найбільш ефективний для SQL Server 7.0 і вище, тому що постачальник даних SQL Server .NET зв'язується безпосередньо з SQL Server через протокол Tabular Data Stream (TDS). Постачальник даних OLE DB .NET необхідний для з'єднання з відмінними від SQL Server базами даних, такими, як Oracle або IBM DB2. Цей постачальник даних використовує OLE DB для відповідних баз даних.
Малюнок 8. Різниця маршрутів в ADO.NET.
На рисунку 8 показані різні шляхи, за якими додаток може зв'язуватися з базою даних через ADO.NET. При виборі шляху спочатку визначається, який постачальник даних .NET буде використовуватися. Якщо це SQL Server 7.0 або більш пізня версія, то підключається постачальник даних SQL Server.NET. Якщо база даних SQL Server 6.5 або відмінна від SQL Server (наприклад, Oracle), знадобиться постачальник даних OLE DB .NET. Зауважимо, що можна задіяти постачальник даних OLE DB .NET для баз даних SQL 7.0 та вище, але тоді загубиться виграш в продуктивності, який дає пряме підключення до SQL Server через протокол TDS. Однак в цьому неспецифічному способі є свій плюс - мобільність, т. Е. Можна міняти бази даних без модифікації коду.
Далі необхідно визначити, яке завдання потрібно виконати. Якщо треба просто прочитати і відобразити дані з джерела даних, об'єкта Data Reader цілком достатньо. Але якщо треба буде маніпулювати даними (наприклад, редагувати або видаляти), потрібно використовувати об'єкт Data Set. Хоча задіяти цей об'єкт слід тільки в разі потреби, тому що він працює повільніше, ніж Data Reader (Data Set використовує Data Reader для заповнення таблиць).
Приклад на ADO.NET
Розглянемо, як ADO.NET діє в Web-службі. У лістингу 2 показана Web-служба, яка повертає об'єкт Data Set. Код в лістингу 2 схожий на код в лістингу 1. Web-служба в лістингу 2 відшукує таблицю Authors в базі Pubs і представляє її як Web-службу. Web-служба використовує постачальник даних SQL Server .NET, як показано в наступному рядку:
Dim conn AS New SqlConnection ( «server = localhost;
uid = sa; password =; database = pubs »)
Потім Web-служба, використовуючи об'єкт Command, виконує запит до бази даних:
Dim comm AS New SqlCommand (sql, conn)
Далі Web-служба за допомогою об'єкта DataAdapter заповнює DataSet:
Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet. Результуючий DataSet повертається як Web-служба. На Екрані 1 показаний ділянку DataSet, який виходить після виклику нової Web-служби. DataSet з його схемою представлений в форматі XML. Клієнтське додаток може вибрати прив'язку до цього DataSet, використовуючи компонент DataGrid. У лістингу 3 показаний код, який виконує цієї комбінації. На Екрані 2 зображений результуючий DataSet, прив'язаний до елементу управління DataGrid в Web-додатку на ASP.NET, яке представить цей DataSet в більш зручному вигляді. ASP.NET підтримує багато елементів управління, які прив'язуються до DataSet автоматично.
Використання ADO в додатках .NET
Хоча в ADO.NET реалізовано багато нових можливостей, можна продовжувати застосовувати ADO. При розробці нової програми на .NET слід віддати перевагу ADO.NET. Але якщо процес розробки триває, можна залишити ADO в старих проектах і використовувати ADO.NET в нових. NET Framework дозволяє задіяти ADO в .NET додатках через COM, який підтримує зворотну сумісність без необхідності модифікувати ADO. Потрібно імпортувати бібліотеки типу ADO як збірку (див. Екран 3). Потім можна використовувати ADO, як показано в коді в лістингу 4.
На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.