Связаться с нами

  • (097) ?601-88-87
    (067) ?493-44-27
    (096) ?830-00-01

Статьи

Еволюція технологій доступу до даних | Windows IT Pro / RE | Видавництво «Відкриті системи»

  1. Еволюція технологій доступу до даних На зорі епохи баз даних розробникам досить було знати лише ті...
  2. DAO і RDO
  3. OLE DB
  4. ADO
  5. Приклад в ADO
  6. Ера .NET
  7. Приклад на ADO.NET
  8. Використання ADO в додатках .NET
  9. НР представляє першу 64-розрядну робочу станцію ХР
  10. Таблиця 1. Деякі особливі об'єкти ADO.NET.
  11. Еволюція технологій доступу до даних
  12. ODBC
  13. DAO і RDO
  14. OLE DB
  15. ADO
  16. Приклад в ADO
  17. Ера .NET
  18. Приклад на ADO.NET
  19. Використання ADO в додатках .NET
  20. НР представляє першу 64-розрядну робочу станцію ХР
  21. Таблиця 1. Деякі особливі об'єкти ADO.NET.
  22. Еволюція технологій доступу до даних
  23. ODBC
  24. DAO і RDO
  25. OLE DB
  26. ADO
  27. Приклад в ADO
  28. Ера .NET
  29. Приклад на ADO.NET
  30. Використання ADO в додатках .NET
  31. НР представляє першу 64-розрядну робочу станцію ХР
  32. Таблиця 1. Деякі особливі об'єкти ADO.NET.

Еволюція технологій доступу до даних

На зорі епохи баз даних розробникам досить було знати лише ті бази даних, які вони використовували. Але бази даних і їх технології розвивалися досить швидко - від реляційних баз даних до нереляційних інформаційних сховищ, таким, як електронна пошта та файлові системи. Розвиток баз даних зараз йде в ногу зі стрімкими змінами в техніці. А з появою клієнт-серверних і багаторівневих архітектур розробникам вже доводиться розбиратися у всьому різноманітті технологій баз даних. Більшість розробників витратили роки на вивчення ODBC, DAO, RDO, OLE DB, ADO і RDS. До теперішнього моменту Microsoft представила .NET Framework і разом з нею нову технологію баз даних ADO.NET.

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

ODBC

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

Технологія ODBC забезпечує загальний інтерфейс для доступу до різнорідних баз даних стандарту SQL. ODBC використовує мову SQL як стандарт для доступу до даних. На рисунку 1 показана архітектура ODBC. Цей інтерфейс дуже зручний: один додаток може звертатися до різних баз даних SQL через загальний набір команд. Таким чином, розробник може створювати і поширювати додатки, не прив'язуючись до конкретної бази даних.

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

DAO і RDO

ODBC використовує низькорівневий інтерфейс, тому програмісти на С і С ++ реально задіюють всі переваги технології ODBC. Програмісти на Visual Basic (VB) не мають простого доступу до інтерфейсу ODBC. До появи VB 6.0 розробники застосовували високорівнева доступ до даних. На рисунку 2 показано, як програмісти VB використовують технологію Data Access Object (DAO) для доступу до данним.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.Чтоби подолати це обмеження, розробники Microsoft створили RDO. На рисунку 3 показано, що RDO звертається до ODBС API безпосередньо, минаючи JET. Потім було введено ODBCDirect, розширення DAO, яке відсуває RDO на задній план. На рисунку 4 показано, як DAO-додаток, використовуючи ODBCDirect, звертається до бази даних, минаючи проблеми, які викликає JET.

OLE DB

Через кілька років ODBC стає стандартом для клієнт-серверного доступу до баз даних. ODBC забезпечує стандартний інтерфейс, який вимагає функцій SQL і оптимізований під методи SQL. Однак що станеться, якщо потрібно буде звернутися до нереляційних базі даних, в якій не використовуються принципи SQL (наприклад, Microsoft Exchange Server, сховище якого не містить дані реляційно).

Розглянемо OLE DB. Технологія OLE DB побудована на ODBC і розширює її до компонентної архітектури, яка забезпечує високорівнева інтерфейс доступу до даних. Ця архітектура надає постійний доступ до SQL-даними, які не SQL-даними і неструктурованих джерел даних по локальних мережах і Internet. Насправді для доступу до SQL-даними OLE DB використовує ODBC, тому що це найбільш підходяща архітектура для роботи з SQL. На рисунку 5 показано, що OLE DB складається з трьох компонентів: споживача даних (наприклад, додатки); постачальника (провайдера) даних, який містить і надає дані; службового компонента, який обробляє і транспортує дані (зокрема, процесори запитів, процесори курсорів). OLE DB - це єдиний API, який обробляє як сумісні з SQL джерела даних, так і несумісні, такі, як пошта і каталоги.

ADO

OLE DB забезпечує зв'язування для програмістів на З і C ++, а також програмістів, що використовують мови з С-подібними викликами функцій. Такі мови, як VB і VBScript, не підтримують тип даних «покажчик» (адресних змінних). Отже, вони не можуть використовувати зв'язування в стилі С і пряме звернення до 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.

Приклад в ADO

Розглянемо простий приклад роботи ADO Розглянемо простий приклад роботи ADO. У лістингу 1 показано, як можна використовувати типовий об'єкт - набір рядків (Recordset) - центральний об'єкт в ADO. Об'єкт Recordset представляє собою набір записів (таблицю) і підтримує типи курсорів adOpenForwardOnly, adOpenKeyset, adOpenDynamic і adOpenStatic. Курсор може бути як на стороні сервера (за замовчуванням), так і на стороні клієнта.

Для доступу до запису ADO потрібно просканувати набір рядків послідовно. Для доступу до декількох таблиць необхідно виконати запит на об'єднання JOIN, щоб отримати результат у вигляді набору рядків. Хоча об'єкт Recordset підтримує доступ до даних без з'єднання з ними, ADO спочатку був спроектований для даних, з якими встановлено з'єднання. Такий метод доступу змушує зберігати важливі ресурси на стороні сервера. До того ж для передачі набору рядків слід використовувати метод упорядкування, названий COM marshalling. COM marshalling - це процес перетворення типів даних, який, природно, займає корисні ресурси системи.

Починаючи з ADO 2.1, Microsoft додає підтримку XML в об'єктну модель ADO, що дозволяє зберігати набір рядків Recordset як XML-документ. Однак тільки при появі ADO 2.5 ряд обмежень XML, який зберігався в версії ADO 2.1 (наприклад, жорстка ієрархія об'єктів Recordset), був усунутий. Хоча ADO може перетворити документ XML в набір Recordset, він в змозі читати тільки документи у власній схемі, відомій як Advanced Data TableGram (ADTG).

У пошуках механізму доступу до непов'язаним даними Microsoft розширює ADO і вводить службу Remote Data Services (RDS). RDS створена після ADO і дозволяє передачу об'єкта Recordset клієнту (наприклад, в Web-браузер) при відсутності активного з'єднання. Однак RDS, як і ADO, використовує упорядкування COM marshaling для передачі набору рядків від сервера клієнту.

Ера .NET

Коли 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.

Постачальники даних .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 для відповідних баз даних.

Під час написання статті розробники Microsoft реалізували третій тип постачальника даних .NET - ODBC .NET Data Provider - Release Candidate Beta. Його можна отримати на сайті Microsoft http://www.microsoft.com/data/ download_odbcnetrc.htm .

На рисунку 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 Розглянемо, як ADO.NET діє в Web-службі. У лістингу 2 показана Web-служба, яка повертає об'єкт Data Set. Код в лістингу 2 схожий на код в лістингу 1. Web-служба в лістингу 2 відшукує таблицю Authors в базі Pubs і представляє її як Web-службу. Web-служба використовує постачальник даних SQL Server .NET, як показано в наступному рядку:

Imports System.Data.SqlClient

Спочатку Web-служба встановлює зв'язок з базою даних SQL Server 2000:

Dim conn AS New SqlConnection ( «server = localhost;
uid = sa; password =; database = pubs »)

Потім Web-служба, використовуючи об'єкт Command, виконує запит до бази даних:

Dim comm AS New SqlCommand (sql, conn)

Далі Web-служба за допомогою об'єкта DataAdapter заповнює DataSet:

DataAdapter.Fill (ds, «Authors_table»)

Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet. Результуючий DataSet повертається як Web-служба. На Екрані 1 показаний ділянку DataSet, який виходить після виклику нової Web-служби. DataSet з його схемою представлений в форматі XML. Клієнтське додаток може вибрати прив'язку до цього DataSet, використовуючи компонент DataGrid. Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet У лістингу 3 показаний код, який виконує цієї комбінації. На Екрані 2 зображений результуючий DataSet, прив'язаний до елементу управління DataGrid в Web-додатку на ASP.NET, яке представить цей DataSet в більш зручному вигляді. ASP.NET підтримує багато елементів управління, які прив'язуються до DataSet автоматично.

Використання ADO в додатках .NET

Хоча в ADO.NET реалізовано багато нових можливостей, можна продовжувати застосовувати ADO. При розробці нової програми на .NET слід віддати перевагу ADO.NET. Хоча в ADO Але якщо процес розробки триває, можна залишити ADO в старих проектах і використовувати ADO.NET в нових. .NET Framework дозволяє задіяти ADO в .NET додатках через COM, який підтримує зворотну сумісність без необхідності модифікувати ADO. Потрібно імпортувати бібліотеки типу ADO як збірку (див. Екран 3). Потім можна використовувати ADO, як показано в коді в лістингу 4.

На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.

НР представляє першу 64-розрядну робочу станцію ХР

HP оголосила про повномасштабну готовності перших робочих станцій на базі процесора Itanium 2, що працюють під управлінням Windows XP 64-Bit Edition Version 2003. Пропонуються дві конструктивні реалізації концепції, а саме: HP Workstation zx2000 і Workstation zx6000 з підтримкою одного і двох процесорів і оперативною пам'яттю 8 Гбайт і 24 Гбайт, відповідно. Як відзначають представники Microsoft, XP 64-Bit Edition Version 2003 є високопродуктивної платформою, здатною підтримувати потужні Windows-додатки нового покоління на робочих станціях на базі Itanium 2. Платформа призначена для обслуговування найбільш складних технічних, наукових і пов'язаних з обробкою цифрової інформації додатків. Стартова цінова планка для робочих станцій HP встановлена ​​на рівні 3300 доларів.

Вей-Менг Лі - викладач інституту School of Information and Communications Technology, Сінгапур. Автор книги «XML Programming using the Microsoft XML parser» (Apress). З ним можна зв'язатися за адресою: [email protected] .

Таблиця 1. Деякі особливі об'єкти ADO.NET.
Об'єктОпис

DataAdapter об'єкт, котрий поєднує базу даних з об'єктом DataSet. Основна перевага DataAdapter полягає в тому, що він може працювати з будь-якими джерелами даних. Джерело даних може бути як базою даних, так і XML-документом. DataReader Об'єкт забезпечує ефективний пошук даних на стороні сервера. DataReader з'єднується в однопрохідному режимі "тільки читання". Цей об'єкт корисний для Web-додатків, які використовують DataReader для відображення даних на Web-сторінках. DataSet Об'єкт підтримує копії записів з бази даних без з'єднання. Він зберігає записи з таблиці (або безлічі таблиць) в пам'яті, не підтримуючи постійного з'єднання з сервером. У пам'яті DataSet представляє собою двійковий об'єкт. Коли його переміщують або перетворять, він представляється як DiffGram - формат XML. Оскільки XML - це текстовий формат, записи можуть передаватися по Web - в обхід обмежень брандмауерів. DataSet також містить різні об'єкти, такі, як обмеження, залежно та подання, які дозволяють працювати з таблицями на клієнтській стороні, а не тільки з RecordSet, як в ADO.

Еволюція технологій доступу до даних

На зорі епохи баз даних розробникам досить було знати лише ті бази даних, які вони використовували. Але бази даних і їх технології розвивалися досить швидко - від реляційних баз даних до нереляційних інформаційних сховищ, таким, як електронна пошта та файлові системи. Розвиток баз даних зараз йде в ногу зі стрімкими змінами в техніці. А з появою клієнт-серверних і багаторівневих архітектур розробникам вже доводиться розбиратися у всьому різноманітті технологій баз даних. Більшість розробників витратили роки на вивчення ODBC, DAO, RDO, OLE DB, ADO і RDS. До теперішнього моменту Microsoft представила .NET Framework і разом з нею нову технологію баз даних ADO.NET.

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

ODBC

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

Технологія ODBC забезпечує загальний інтерфейс для доступу до різнорідних баз даних стандарту SQL. ODBC використовує мову SQL як стандарт для доступу до даних. На рисунку 1 показана архітектура ODBC. Цей інтерфейс дуже зручний: один додаток може звертатися до різних баз даних SQL через загальний набір команд. Таким чином, розробник може створювати і поширювати додатки, не прив'язуючись до конкретної бази даних.

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

DAO і RDO

ODBC використовує низькорівневий інтерфейс, тому програмісти на С і С ++ реально задіюють всі переваги технології ODBC. Програмісти на Visual Basic (VB) не мають простого доступу до інтерфейсу ODBC. До появи VB 6.0 розробники застосовували високорівнева доступ до даних. На рисунку 2 показано, як програмісти VB використовують технологію Data Access Object (DAO) для доступу до данним.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.Чтоби подолати це обмеження, розробники Microsoft створили RDO. На рисунку 3 показано, що RDO звертається до ODBС API безпосередньо, минаючи JET. Потім було введено ODBCDirect, розширення DAO, яке відсуває RDO на задній план. На рисунку 4 показано, як DAO-додаток, використовуючи ODBCDirect, звертається до бази даних, минаючи проблеми, які викликає JET.

OLE DB

Через кілька років ODBC стає стандартом для клієнт-серверного доступу до баз даних. ODBC забезпечує стандартний інтерфейс, який вимагає функцій SQL і оптимізований під методи SQL. Однак що станеться, якщо потрібно буде звернутися до нереляційних базі даних, в якій не використовуються принципи SQL (наприклад, Microsoft Exchange Server, сховище якого не містить дані реляційно).

Розглянемо OLE DB. Технологія OLE DB побудована на ODBC і розширює її до компонентної архітектури, яка забезпечує високорівнева інтерфейс доступу до даних. Ця архітектура надає постійний доступ до SQL-даними, які не SQL-даними і неструктурованих джерел даних по локальних мережах і Internet. Насправді для доступу до SQL-даними OLE DB використовує ODBC, тому що це найбільш підходяща архітектура для роботи з SQL. На рисунку 5 показано, що OLE DB складається з трьох компонентів: споживача даних (наприклад, додатки); постачальника (провайдера) даних, який містить і надає дані; службового компонента, який обробляє і транспортує дані (зокрема, процесори запитів, процесори курсорів). OLE DB - це єдиний API, який обробляє як сумісні з SQL джерела даних, так і несумісні, такі, як пошта і каталоги.

ADO

OLE DB забезпечує зв'язування для програмістів на З і C ++, а також програмістів, що використовують мови з С-подібними викликами функцій. Такі мови, як VB і VBScript, не підтримують тип даних «покажчик» (адресних змінних). Отже, вони не можуть використовувати зв'язування в стилі С і пряме звернення до 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.

Приклад в ADO

Розглянемо простий приклад роботи ADO Розглянемо простий приклад роботи ADO. У лістингу 1 показано, як можна використовувати типовий об'єкт - набір рядків (Recordset) - центральний об'єкт в ADO. Об'єкт Recordset представляє собою набір записів (таблицю) і підтримує типи курсорів adOpenForwardOnly, adOpenKeyset, adOpenDynamic і adOpenStatic. Курсор може бути як на стороні сервера (за замовчуванням), так і на стороні клієнта.

Для доступу до запису ADO потрібно просканувати набір рядків послідовно. Для доступу до декількох таблиць необхідно виконати запит на об'єднання JOIN, щоб отримати результат у вигляді набору рядків. Хоча об'єкт Recordset підтримує доступ до даних без з'єднання з ними, ADO спочатку був спроектований для даних, з якими встановлено з'єднання. Такий метод доступу змушує зберігати важливі ресурси на стороні сервера. До того ж для передачі набору рядків слід використовувати метод упорядкування, названий COM marshalling. COM marshalling - це процес перетворення типів даних, який, природно, займає корисні ресурси системи.

Починаючи з ADO 2.1, Microsoft додає підтримку XML в об'єктну модель ADO, що дозволяє зберігати набір рядків Recordset як XML-документ. Однак тільки при появі ADO 2.5 ряд обмежень XML, який зберігався в версії ADO 2.1 (наприклад, жорстка ієрархія об'єктів Recordset), був усунутий. Хоча ADO може перетворити документ XML в набір Recordset, він в змозі читати тільки документи у власній схемі, відомій як Advanced Data TableGram (ADTG).

У пошуках механізму доступу до непов'язаним даними Microsoft розширює ADO і вводить службу Remote Data Services (RDS). RDS створена після ADO і дозволяє передачу об'єкта Recordset клієнту (наприклад, в Web-браузер) при відсутності активного з'єднання. Однак RDS, як і ADO, використовує упорядкування COM marshaling для передачі набору рядків від сервера клієнту.

Ера .NET

Коли 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.

Постачальники даних .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 для відповідних баз даних.

Під час написання статті розробники Microsoft реалізували третій тип постачальника даних .NET - ODBC .NET Data Provider - Release Candidate Beta. Його можна отримати на сайті Microsoft http://www.microsoft.com/data/ download_odbcnetrc.htm .

На рисунку 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 Розглянемо, як ADO.NET діє в Web-службі. У лістингу 2 показана Web-служба, яка повертає об'єкт Data Set. Код в лістингу 2 схожий на код в лістингу 1. Web-служба в лістингу 2 відшукує таблицю Authors в базі Pubs і представляє її як Web-службу. Web-служба використовує постачальник даних SQL Server .NET, як показано в наступному рядку:

Imports System.Data.SqlClient

Спочатку Web-служба встановлює зв'язок з базою даних SQL Server 2000:

Dim conn AS New SqlConnection ( «server = localhost;
uid = sa; password =; database = pubs »)

Потім Web-служба, використовуючи об'єкт Command, виконує запит до бази даних:

Dim comm AS New SqlCommand (sql, conn)

Далі Web-служба за допомогою об'єкта DataAdapter заповнює DataSet:

DataAdapter.Fill (ds, «Authors_table»)

Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet. Результуючий DataSet повертається як Web-служба. На Екрані 1 показаний ділянку DataSet, який виходить після виклику нової Web-служби. DataSet з його схемою представлений в форматі XML. Клієнтське додаток може вибрати прив'язку до цього DataSet, використовуючи компонент DataGrid. Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet У лістингу 3 показаний код, який виконує цієї комбінації. На Екрані 2 зображений результуючий DataSet, прив'язаний до елементу управління DataGrid в Web-додатку на ASP.NET, яке представить цей DataSet в більш зручному вигляді. ASP.NET підтримує багато елементів управління, які прив'язуються до DataSet автоматично.

Використання ADO в додатках .NET

Хоча в ADO.NET реалізовано багато нових можливостей, можна продовжувати застосовувати ADO. При розробці нової програми на .NET слід віддати перевагу ADO.NET. Хоча в ADO Але якщо процес розробки триває, можна залишити ADO в старих проектах і використовувати ADO.NET в нових. .NET Framework дозволяє задіяти ADO в .NET додатках через COM, який підтримує зворотну сумісність без необхідності модифікувати ADO. Потрібно імпортувати бібліотеки типу ADO як збірку (див. Екран 3). Потім можна використовувати ADO, як показано в коді в лістингу 4.

На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.

НР представляє першу 64-розрядну робочу станцію ХР

HP оголосила про повномасштабну готовності перших робочих станцій на базі процесора Itanium 2, що працюють під управлінням Windows XP 64-Bit Edition Version 2003. Пропонуються дві конструктивні реалізації концепції, а саме: HP Workstation zx2000 і Workstation zx6000 з підтримкою одного і двох процесорів і оперативною пам'яттю 8 Гбайт і 24 Гбайт, відповідно. Як відзначають представники Microsoft, XP 64-Bit Edition Version 2003 є високопродуктивної платформою, здатною підтримувати потужні Windows-додатки нового покоління на робочих станціях на базі Itanium 2. Платформа призначена для обслуговування найбільш складних технічних, наукових і пов'язаних з обробкою цифрової інформації додатків. Стартова цінова планка для робочих станцій HP встановлена ​​на рівні 3300 доларів.

Вей-Менг Лі - викладач інституту School of Information and Communications Technology, Сінгапур. Автор книги «XML Programming using the Microsoft XML parser» (Apress). З ним можна зв'язатися за адресою: [email protected] .

Таблиця 1. Деякі особливі об'єкти ADO.NET.
Об'єктОпис

DataAdapter об'єкт, котрий поєднує базу даних з об'єктом DataSet. Основна перевага DataAdapter полягає в тому, що він може працювати з будь-якими джерелами даних. Джерело даних може бути як базою даних, так і XML-документом. DataReader Об'єкт забезпечує ефективний пошук даних на стороні сервера. DataReader з'єднується в однопрохідному режимі "тільки читання". Цей об'єкт корисний для Web-додатків, які використовують DataReader для відображення даних на Web-сторінках. DataSet Об'єкт підтримує копії записів з бази даних без з'єднання. Він зберігає записи з таблиці (або безлічі таблиць) в пам'яті, не підтримуючи постійного з'єднання з сервером. У пам'яті DataSet представляє собою двійковий об'єкт. Коли його переміщують або перетворять, він представляється як DiffGram - формат XML. Оскільки XML - це текстовий формат, записи можуть передаватися по Web - в обхід обмежень брандмауерів. DataSet також містить різні об'єкти, такі, як обмеження, залежно та подання, які дозволяють працювати з таблицями на клієнтській стороні, а не тільки з RecordSet, як в ADO.

Еволюція технологій доступу до даних

На зорі епохи баз даних розробникам досить було знати лише ті бази даних, які вони використовували. Але бази даних і їх технології розвивалися досить швидко - від реляційних баз даних до нереляційних інформаційних сховищ, таким, як електронна пошта та файлові системи. Розвиток баз даних зараз йде в ногу зі стрімкими змінами в техніці. А з появою клієнт-серверних і багаторівневих архітектур розробникам вже доводиться розбиратися у всьому різноманітті технологій баз даних. Більшість розробників витратили роки на вивчення ODBC, DAO, RDO, OLE DB, ADO і RDS. До теперішнього моменту Microsoft представила .NET Framework і разом з нею нову технологію баз даних ADO.NET.

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

ODBC

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

Технологія ODBC забезпечує загальний інтерфейс для доступу до різнорідних баз даних стандарту SQL. ODBC використовує мову SQL як стандарт для доступу до даних. На рисунку 1 показана архітектура ODBC. Цей інтерфейс дуже зручний: один додаток може звертатися до різних баз даних SQL через загальний набір команд. Таким чином, розробник може створювати і поширювати додатки, не прив'язуючись до конкретної бази даних.

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

DAO і RDO

ODBC використовує низькорівневий інтерфейс, тому програмісти на С і С ++ реально задіюють всі переваги технології ODBC. Програмісти на Visual Basic (VB) не мають простого доступу до інтерфейсу ODBC. До появи VB 6.0 розробники застосовували високорівнева доступ до даних. На рисунку 2 показано, як програмісти VB використовують технологію Data Access Object (DAO) для доступу до данним.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.Чтоби подолати це обмеження, розробники Microsoft створили RDO. На рисунку 3 показано, що RDO звертається до ODBС API безпосередньо, минаючи JET. Потім було введено ODBCDirect, розширення DAO, яке відсуває RDO на задній план. На рисунку 4 показано, як DAO-додаток, використовуючи ODBCDirect, звертається до бази даних, минаючи проблеми, які викликає JET.

OLE DB

Через кілька років ODBC стає стандартом для клієнт-серверного доступу до баз даних. ODBC забезпечує стандартний інтерфейс, який вимагає функцій SQL і оптимізований під методи SQL. Однак що станеться, якщо потрібно буде звернутися до нереляційних базі даних, в якій не використовуються принципи SQL (наприклад, Microsoft Exchange Server, сховище якого не містить дані реляційно).

Розглянемо OLE DB. Технологія OLE DB побудована на ODBC і розширює її до компонентної архітектури, яка забезпечує високорівнева інтерфейс доступу до даних. Ця архітектура надає постійний доступ до SQL-даними, які не SQL-даними і неструктурованих джерел даних по локальних мережах і Internet. Насправді для доступу до SQL-даними OLE DB використовує ODBC, тому що це найбільш підходяща архітектура для роботи з SQL. На рисунку 5 показано, що OLE DB складається з трьох компонентів: споживача даних (наприклад, додатки); постачальника (провайдера) даних, який містить і надає дані; службового компонента, який обробляє і транспортує дані (зокрема, процесори запитів, процесори курсорів). OLE DB - це єдиний API, який обробляє як сумісні з SQL джерела даних, так і несумісні, такі, як пошта і каталоги.

ADO

OLE DB забезпечує зв'язування для програмістів на З і C ++, а також програмістів, що використовують мови з С-подібними викликами функцій. Такі мови, як VB і VBScript, не підтримують тип даних «покажчик» (адресних змінних). Отже, вони не можуть використовувати зв'язування в стилі С і пряме звернення до 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.

Приклад в ADO

Розглянемо простий приклад роботи ADO Розглянемо простий приклад роботи ADO. У лістингу 1 показано, як можна використовувати типовий об'єкт - набір рядків (Recordset) - центральний об'єкт в ADO. Об'єкт Recordset представляє собою набір записів (таблицю) і підтримує типи курсорів adOpenForwardOnly, adOpenKeyset, adOpenDynamic і adOpenStatic. Курсор може бути як на стороні сервера (за замовчуванням), так і на стороні клієнта.

Для доступу до запису ADO потрібно просканувати набір рядків послідовно. Для доступу до декількох таблиць необхідно виконати запит на об'єднання JOIN, щоб отримати результат у вигляді набору рядків. Хоча об'єкт Recordset підтримує доступ до даних без з'єднання з ними, ADO спочатку був спроектований для даних, з якими встановлено з'єднання. Такий метод доступу змушує зберігати важливі ресурси на стороні сервера. До того ж для передачі набору рядків слід використовувати метод упорядкування, названий COM marshalling. COM marshalling - це процес перетворення типів даних, який, природно, займає корисні ресурси системи.

Починаючи з ADO 2.1, Microsoft додає підтримку XML в об'єктну модель ADO, що дозволяє зберігати набір рядків Recordset як XML-документ. Однак тільки при появі ADO 2.5 ряд обмежень XML, який зберігався в версії ADO 2.1 (наприклад, жорстка ієрархія об'єктів Recordset), був усунутий. Хоча ADO може перетворити документ XML в набір Recordset, він в змозі читати тільки документи у власній схемі, відомій як Advanced Data TableGram (ADTG).

У пошуках механізму доступу до непов'язаним даними Microsoft розширює ADO і вводить службу Remote Data Services (RDS). RDS створена після ADO і дозволяє передачу об'єкта Recordset клієнту (наприклад, в Web-браузер) при відсутності активного з'єднання. Однак RDS, як і ADO, використовує упорядкування COM marshaling для передачі набору рядків від сервера клієнту.

Ера .NET

Коли 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.

Постачальники даних .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 для відповідних баз даних.

Під час написання статті розробники Microsoft реалізували третій тип постачальника даних .NET - ODBC .NET Data Provider - Release Candidate Beta. Його можна отримати на сайті Microsoft http://www.microsoft.com/data/ download_odbcnetrc.htm .

На рисунку 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 Розглянемо, як ADO.NET діє в Web-службі. У лістингу 2 показана Web-служба, яка повертає об'єкт Data Set. Код в лістингу 2 схожий на код в лістингу 1. Web-служба в лістингу 2 відшукує таблицю Authors в базі Pubs і представляє її як Web-службу. Web-служба використовує постачальник даних SQL Server .NET, як показано в наступному рядку:

Imports System.Data.SqlClient

Спочатку Web-служба встановлює зв'язок з базою даних SQL Server 2000:

Dim conn AS New SqlConnection ( «server = localhost;
uid = sa; password =; database = pubs »)

Потім Web-служба, використовуючи об'єкт Command, виконує запит до бази даних:

Dim comm AS New SqlCommand (sql, conn)

Далі Web-служба за допомогою об'єкта DataAdapter заповнює DataSet:

DataAdapter.Fill (ds, «Authors_table»)

Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet. Результуючий DataSet повертається як Web-служба. На Екрані 1 показаний ділянку DataSet, який виходить після виклику нової Web-служби. DataSet з його схемою представлений в форматі XML. Клієнтське додаток може вибрати прив'язку до цього DataSet, використовуючи компонент DataGrid. Зауважимо, що з'єднання закривається, як тільки Dataset заповнений, на відміну від сполук в ADO, які повинні бути відкриті, поки існує з'єднання через RecordSet У лістингу 3 показаний код, який виконує цієї комбінації. На Екрані 2 зображений результуючий DataSet, прив'язаний до елементу управління DataGrid в Web-додатку на ASP.NET, яке представить цей DataSet в більш зручному вигляді. ASP.NET підтримує багато елементів управління, які прив'язуються до DataSet автоматично.

Використання ADO в додатках .NET

Хоча в ADO.NET реалізовано багато нових можливостей, можна продовжувати застосовувати ADO. При розробці нової програми на .NET слід віддати перевагу ADO.NET. Хоча в ADO Але якщо процес розробки триває, можна залишити ADO в старих проектах і використовувати ADO.NET в нових. .NET Framework дозволяє задіяти ADO в .NET додатках через COM, який підтримує зворотну сумісність без необхідності модифікувати ADO. Потрібно імпортувати бібліотеки типу ADO як збірку (див. Екран 3). Потім можна використовувати ADO, як показано в коді в лістингу 4.

На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.

НР представляє першу 64-розрядну робочу станцію ХР

HP оголосила про повномасштабну готовності перших робочих станцій на базі процесора Itanium 2, що працюють під управлінням Windows XP 64-Bit Edition Version 2003. Пропонуються дві конструктивні реалізації концепції, а саме: HP Workstation zx2000 і Workstation zx6000 з підтримкою одного і двох процесорів і оперативною пам'яттю 8 Гбайт і 24 Гбайт, відповідно. Як відзначають представники Microsoft, XP 64-Bit Edition Version 2003 є високопродуктивної платформою, здатною підтримувати потужні Windows-додатки нового покоління на робочих станціях на базі Itanium 2. Платформа призначена для обслуговування найбільш складних технічних, наукових і пов'язаних з обробкою цифрової інформації додатків. Стартова цінова планка для робочих станцій HP встановлена ​​на рівні 3300 доларів.

Вей-Менг Лі - викладач інституту School of Information and Communications Technology, Сінгапур. Автор книги «XML Programming using the Microsoft XML parser» (Apress). З ним можна зв'язатися за адресою: [email protected] .

Таблиця 1. Деякі особливі об'єкти ADO.NET.
Об'єктОпис

DataAdapter об'єкт, котрий поєднує базу даних з об'єктом DataSet. Основна перевага DataAdapter полягає в тому, що він може працювати з будь-якими джерелами даних. Джерело даних може бути як базою даних, так і XML-документом. DataReader Об'єкт забезпечує ефективний пошук даних на стороні сервера. DataReader з'єднується в однопрохідному режимі "тільки читання". Цей об'єкт корисний для Web-додатків, які використовують DataReader для відображення даних на Web-сторінках. DataSet Об'єкт підтримує копії записів з бази даних без з'єднання. Він зберігає записи з таблиці (або безлічі таблиць) в пам'яті, не підтримуючи постійного з'єднання з сервером. У пам'яті DataSet представляє собою двійковий об'єкт. Коли його переміщують або перетворять, він представляється як DiffGram - формат XML. Оскільки XML - це текстовий формат, записи можуть передаватися по Web - в обхід обмежень брандмауерів. DataSet також містить різні об'єкти, такі, як обмеження, залежно та подання, які дозволяють працювати з таблицями на клієнтській стороні, а не тільки з RecordSet, як в ADO.

Новости

Все товары для праздника оптом купить
Как сделать правильный выбор в работе, бизнесе и жизни, о котором никогда не придется жалеть. Мы хотим рассказать вам об удивительной и очень простой технике 7 вопросов, которые позволят оценить ситуацию

Как сделать красивую снежинку из бумаги
Красивые бумажные снежинки станут хорошим украшением дома на Новый год. Они создадут в квартире атмосферу белоснежной, зимней сказки. Да и просто занимаясь вырезанием из бумаги снежинок разнообразной

Пиротехника своими руками в домашних
Самые лучшие полезные самоделки рунета! Как сделать самому, мастер-классы, фото, чертежи, инструкции, книги, видео. Главная САМОДЕЛКИ Дизайнерские

Фольгированные шары с гелием
Для начала давайте разберемся и чего же выполнен фольгированный шар и почему он летает дольше?! Как вы помните, наши латексные шарики достаточно пористые, поэтому их приходится обрабатывать специальным

Надувные шарики с гелием с доставкой
На праздники часто бывают востребованы воздушные шарики, надутые гелием. Обычно, их покупают уже готовыми (надутыми) и привозят на праздник. Или, приглашают специалистов, которые приезжают и надувают

Аниматоры на детские праздники в Зеленограде
Уж сколько раз твердили миру…Что готовиться ко дню рождения нужно заранее, а не бегать в предпраздничный день угорелой кошкой. Нельзя впихнуть в 24 часа дела, рассчитанные на недели. К празднику нужно

2400 наименований пиротехники
В последние десятилетия наша страна может похвастаться появлением нескольких десятков отечественных производителей, специализирующихся на выпуске пиротехники. Если вы сомневаетесь, какой фейерверк заказать,