- Еволюція технологій доступу до даних На зорі епохи баз даних розробникам досить було знати лише ті...
- DAO і RDO
- OLE DB
- ADO
- Приклад в ADO
- Ера .NET
- Приклад на ADO.NET
- Використання ADO в додатках .NET
- НР представляє першу 64-розрядну робочу станцію ХР
- Таблиця 1. Деякі особливі об'єкти ADO.NET.
- Еволюція технологій доступу до даних
- ODBC
- DAO і RDO
- OLE DB
- ADO
- Приклад в ADO
- Ера .NET
- Приклад на ADO.NET
- Використання ADO в додатках .NET
- НР представляє першу 64-розрядну робочу станцію ХР
- Таблиця 1. Деякі особливі об'єкти ADO.NET.
- Еволюція технологій доступу до даних
- ODBC
- DAO і RDO
- OLE DB
- ADO
- Приклад в ADO
- Ера .NET
- Приклад на ADO.NET
- Використання ADO в додатках .NET
- НР представляє першу 64-розрядну робочу станцію ХР
- Таблиця 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. У лістингу 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.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. У лістингу 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.
На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.
НР представляє першу 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. У лістингу 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.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. У лістингу 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.
На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.
НР представляє першу 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. У лістингу 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.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. У лістингу 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.
На закінчення хочу додати, що технології доступу до баз даних постійно розвиваються. Поки освоюється одна технологія, вже з'являється інша. Тільки одне залишається незмінним: бази даних відіграють все більш важливу роль при розробці додатків. Знання новітніх технологій і еволюційних змін, які вони викликають, допоможе знайти оптимальну технологію для поточного завдання і зробити обґрунтований вибір в разі необхідних змін.
НР представляє першу 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.