Огляд AD0.NET – ЧАСТИНА 2

Додаткова Читачі, які бажають ближче ознайомитися з ієрархіями СоТуре і OLE DB, мо-ііформаіій рут звернутися до статті Introduction to OLE DB Programing в бібліотеці MSDN:

‘ -•-*■***http: //msdnmicrosoft com/library/default aspurl =/library/ en-us/oledb/htm/oledbpartl_introduction_to_ole_dbasp

Кількість CoTypes в OLE DB вкрай велике Найпотужнішим і корисним властивістю OLE DB є здатність виражати і передавати всі поставляються дані споживачеві в найпростіших термінах значення, його довжини і відмінних характеристик, таких як стан В ідеальному випадку станом буде DBPROPSTATUS_OK (тобто ознака хороших даних), в той же час стан може вказувати серед іншого на порожнє значення, зіпсовані дані або за яким критерієм дані вважаються зіпсованими

OLE DB (як, в принципі, і всі інші компоненти СОМ) не залежить від використовуваних мов програмування Це робить даний інтерфейс ідеальної низкоуровневой архітектурою для мов високого рівня, що використовують ADO Низькорівневі специфікації здатні залишитися незмінними, у той час як обєктна модель ADO може бути описана в VB, С #, на мовах сценаріїв VBScript і JScript і на мовах, здатних увійти в простір низкоуровневой специфікації, таких як C + + OLE DB є могутнім програмним рішенням, призначеним для обробки інформації з баз даних і інших джерел у наборах записів і потоках Обєктна модель ADO робить інтерфейс OLE DB доступним для розробників, створюючи його оболонку Водночас її не можна назвати остаточним рішенням доступу до даних

Якщо програміст неправильно визначив область памяті, а компілятор не Увага перевіряє безпеку типів, можуть виникнути витоку памяті і помилки доступу до даних, що порушить стійкість бази даних та програми Витоку памяті виникають, коли додаток виділяє память, але не повертає її в пул вільної памяті після того, як потреба в даній області відпала Помилки доступу виникають, коли програма намагається прочитати або записати за адресою, яка вже використовується іншим потоком виконання Компілятор C + + в Visual Studio2005 не може перевірити коректність посилань на області памяті, тому дана мова не захищає програміста від потенційно небезпечних дефектів у програмному коді Компілятори VBNET і, з деякою натяжкою, компілятори С #, так само як і Windows Scripting Host, пропонують більш досконалу захист від таких спотворень памяті Утиліта PEVerify, що входить до складу NET Framework 20 SDK, може бути використана для ідентифікації безпечного для типів коду MSIL У той же час ця утиліта зовсім марна при пошуку місцезнаходження і типів дефектів захисту типів у вихідному програмному коді

Первинні interop-збірки AD0DB

СОМ і NET є сумісними технологіями Збірки NET можуть використовуватися в додатках СОМ, а компоненти СОМ – в програмному коді NET Збірки NET можуть управлятися облачком СОМ Оболонка СОМ повинна реалізувати ядро ​​interop-збірки СОМ За своєю суттю interop-збірки є метаданими (або визначеннями типів) для компонентів СОМ, вираженими в керованому коді

Додаткову інформацію з питання інтероперабельності компонентів СОМ і NET ви можете знайти в статті Microsoft NET / COM Migration and Interoperability, розміщеної за адресою:

http://msdnmicrosoftcom/library/defaultaspurl=/library/ en-us/dnbda/html/cominteropasp

Первинна interop-збірка (далі PIA) підписується власником обєкта COM PIA є interop-збіркою, рекомендованої для використання в середовищі NET Framework при розкритті обєкту СОМ в керованому коді Компанія Microsoft пропонує такі підписані PIA для ADO в середовищі розробки Visual Studio NET – вони містяться в збірці adodb Dll Microsoft рекомендує використовувати тільки цю збірку при використанні ADO в керованому коді NET Як показано на рис 302, всі посилання для первинної interop-збірки вибираються зі списку посилань NET при додаванні в проект Visual Studio, а не за допомогою додавання посилання на компонент ADO у вкладці СОМ діалогового вікна Add Reference

Слід зробити ще одне зауваження, що стосується використання ADO в Visual Studio 2005 Справа в тому, що клієнт SNAC не підтримує обєктну модель ADO, а це означає, що для доступу до SQL Server додатки ADO повинні покладатися виключно на компоненти MDAC ADONET підтримується клієнтом SNAC і не вимагає координації зі складною павутиною бібліотек і компонентів MDAC

Рис 302 Вибір adodb dll в якості посилання NET в проекті Visual Studio

MDAC стає складовою частиною різних операційних систем від Microsoft і надалі не буде виходити в світ окремо від них Спеціально встановлена ​​бібліотека MDAC не використовується ні в одному прикладі цієї глави Тут використовуються драйвери MDAC, що поставляються з операційними системами Windows ХР SP2, Windows ХР х64, Windows Server 2003 R2 Standard і Windows Server 2003 R2 Enterprise x64 Навряд чи Microsoft випускатиме надалі нові версії відокремлених бібліотек MDAC Можливо, кращим місцем відстеження змін в MDAC стане документація до нових версій операційних систем, пакетів ообновленія і заплаток Аналогічно, сумісність версій MDAC перевірятиметься методом тестування змін, застосованих до операційної системи

SNAC є програмним інтерфейсом, абсолютно не повязаним з MDAC Цей інтерфейс був розроблений для спрощення синхронізації оновлення клієнтів з сервером Коли клієнти SQL покладаються на компоненти MDAC, поновлення цих компонентів, необхідні для сумісності клієнта і бази даних, можуть викликати проблеми в інших компонентах додатків, запущених у клієнта Звідси випливає, що зміни MDAC, необхідні для інших програм, можуть викликати проблеми з підключеннями до SQL Server У SNAC клієнт SQL міститься всього в одному файлі Dll Ризик, повязаний із зміною SNAC на сервері додатків, є мізерним в порівнянні з ризиком, повязаним із зміною MDAC

Із змінами в MDAC і SNAC також можна ознайомитися в центрі розробників Data Access and Storage Developer Center за адресою:

http://msdnmicrosoftcom/data/defaultaspx

Одним з найбільш інформативних документів, які можна там знайти, є Data Access Technologies Road Map:

http://msdnmicrosoftcom/data/mdac/defaultaspxpull=/ library/en-us/dnmdac/html/data_mdacroadmapasp

Обєктна модель ADO

До цих пір в цьому розділі ми говорили про місце ADO в світі NET та інфраструктурі OLE DB, а також про методи використання ADO в середовищі NET Framework Тепер подивимося, як ADO вписується (або більш доречно сказати – не вписується) в загальну схему ADONET

Одним з основних завдань ADONET була реалізація всіх можливостей, закладених у старій добрій обєктної моделі ADO Як мінімум, ADO є рольовою моделлю ADONET Версії ADONET 1x постали перед нами з дещо скороченим набором можливостей ADO, в результаті чого реалізація засобів NET була обмежена простором доступу до даних З виходом версій ADONET 20 і SQL Server 2005 повний набір коштів ADO був обєднаний з незалежністю і безпекою середовища NET Framework і перспективами XML Не можна сказати, щоб не потрібно було ніякої роботи і щоб ADO була повністю реалізована у своєму нащадку, особливо в питаннях продуктивності Зрозуміти произошедшую трансформацію можна тільки за допомогою порівняння цих двох обєктних моделей Для адекватного порівняння розглянемо функції і компоненти обєктної моделі ADO Це закладе фундамент для подальшої оцінки того, що зявилося нового і що було покращено в ADONET

Обєктна модель ADO є не просто оболонкою інтерфейсу OLE DB Вона представляє реальну цінність для розробника і має деякі переваги перед попередніми методами доступу до даних Нижче коротко перераховані ці переваги

■ Незалежне створення обєктів У ADO більше немає необхідності послідовно проходити по ієрархії обєктів Розробник створює тільки необхідний йому обєкт, таким чином, знижуючи навантаження на память, підвищуючи швидкість виконання програми та зменшуючи кількість рядків програмного коду

■ Пакетне оновлення Замість відправки на сервер одного повідомлення вони можуть накопичуватися в локальній памяті і відправлятися одночасно Використання цієї функції підвищує продуктивність програми (тому що постачальник даних може виконувати оновлення в фоновому режимі) і скорочує навантаження на мережу

Збережені процедури Ці процедури зберігаються і виконуються на серверній стороні СУБД Вони використовуються для виконання конкретних завдань з наборами даних ADO використовує збережені процедури з вхідними і вихідними параметрами і повертає значення

■ Безліч типів курсорів Курсори вказують на рядок, з якою виконується робота в поточний момент Курсори можуть розташовуватися як на стороні сервера, так і на стороні клієнта

Додаткова Дуже важливо розуміти відмінності клієнтського курсора в додатку і курсора інформація Т-SQL Перші надають досить слабкий вплив на продуктивність

З іншого боку, використання серверних курсорів, особливо оновлюваних, може негативно позначитися на базі даних Детально про курсором см в главі 20

■ Обмеження числа що повертаються рядків Ця функція дозволяє обмежити кількість повертаних запитом рядків тільки тими, які дійсно потрібні користувачеві

■ Безліч обєктів наборів записів Можливість роботи з безліччю наборів даних, що повертаються збереженої процедурою або пакетом інструкцій

■ Вільні потокові обєкти Ця функція підвищує продуктивність Web-сервера, дозволяючи йому одночасно виконувати кілька завдань

Подібно до всіх компонентів OLE DB, ADO використовує COM ADO надає двоїстий інтерфейс: ідентифікатор програми ADODB для локальних операцій та ідентифікатор ADOR – для віддалених Сама бібліотека ADO працює з вільними потоками, незважаючи на те, що в реєстрі вона показана як використовує модель з розділеними потоками Безпека потоків в ADO залежить від використовуваного постачальника OLE DB Іншими

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*