ado net технология за достъп до данни. ADO.NET технологии

Последна актуализация: 31.10.2015 г

Днес работата с данни е от голямо значение. За съхраняване на данни се използват различни системи за управление на бази данни: MS SQL Server, Oracle, MySQL и др. И повечето големи приложения използват тези системи за управление на бази данни, за да съхраняват данни по един или друг начин. Въпреки това, за комуникация между базата данни и C# приложението е необходим посредник. А технологията ADO.NET е точно такъв посредник.

ADO.NET предоставя технология за наука за данни, която е базирана на .NET Framework. Тази технология ни предоставя набор от класове, чрез които можем да изпращаме заявки към бази данни, да установяваме връзки, да получаваме отговор от базата данни и да извършваме редица други операции.

Освен това е важно да се отбележи, че може да има много системи за управление на бази данни. По своята същност те могат да се различават. MS SQL Server, например, използва езика T-SQL за създаване на заявки, докато MySQL и Oracle използват езика PL-SQL. Различните системи за бази данни могат да имат различни типове данни. Някои други точки също могат да варират. Функционалността на ADO.NET обаче е изградена по такъв начин, че да предостави на разработчиците унифициран интерфейс за работа с голямо разнообразие от СУБД.

Основата на интерфейса за взаимодействие с бази данни в ADO.NET е представена от ограничен набор от обекти: Connection, Command, DataReader, DataSet и DataAdapter. С помощта на обекта Connection се установява връзка с източник на данни. Обектът Command ви позволява да извършвате операции с данни от базата данни. Обектът DataReader чете данните, получени в резултат на заявката. Обектът DataSet е проектиран да съхранява данни от база данни и ви позволява да работите с него независимо от базата данни. А обектът DataAdapter е посредникът между DataSet и източника на данни. Основно работата с базата данни ще се осъществява чрез тези обекти.

Въпреки това, за да използвате един и същ набор от обекти за различни източници на данни, имате нужда от подходящ доставчик на данни. Именно чрез доставчика на данни в ADO.NET се осъществява взаимодействието с базата данни. Освен това за всеки източник на данни в ADO.NET може да има свой собствен доставчик, който всъщност дефинира конкретната имплементация на горните класове.

По подразбиране ADO.NET има следните вградени доставчици:

    Доставчик за MS SQL Server

    Доставчик за OLE DB (Осигурява достъп до някои по-стари версии на MS SQL Server, както и бази данни Access, DB2, MySQL и Oracle)

    Доставчик за ODBC (доставчик за тези източници на данни, които нямат свои собствени доставчици)

    Доставчик за Oracle

    Доставчик EntityClient. Доставчик на данни за технологията ORM Entity Framework

    Доставчик за SQL Server Compact 4.0

В допълнение към тези доставчици, които са вградени, има и много други, предназначени за различни бази данни, например MySQL.

Основните пространства от имена, използвани в ADO.NET, са:

    System.Data: дефинира класове, интерфейси, делегати, които имплементират ADO.NET архитектурата

    System.Data.Common: Съдържа класове, общи за всички ADO.NET доставчици

    System.Data.Design: Дефинира класове, които се използват за създаване на собствени набори от данни

    System.Data.Odbc: Дефинира функционалността на доставчика на данни за ODBC

    System.Data.OleDb: Дефинира функционалността на доставчика на данни за OLE DB

    System.Data.Sql: съхранява класове, които поддържат специфична за SQL Server функционалност

    System.Data.OracleClient: Дефинира функционалността на доставчика за бази данни на Oracle

    System.Data.SqlClient: дефинира функционалността на доставчика за бази данни на MS SQL Server

    System.Data.SqlServerCe: Дефинира функционалност на доставчика за SQL Server Compact 4.0

    System.Data.SqlTypes: съдържа класове за типове данни на MS SQL Server

    Microsoft.SqlServer.Server: Съхранява компоненти за взаимодействие между SQL Server и CLR

Архитектурата на ADO.NET може да бъде схематично представена по следния начин:

Функционално класовете на ADO.NET могат да бъдат разделени на две нива: свързани и несвързани. Всеки .NET доставчик на данни внедрява своя собствена версия на Connection, Command, DataReader, DataAdapter и няколко други обекта, които съставляват свързания слой. Тоест, те се използват за установяване на връзка с базата данни и взаимодействие с нея. По правило реализациите на тези обекти за всеки конкретен доставчик имат префикс в името си, който указва доставчика:

Други класове като DataSet, DataTable, DataRow, DataColumn и няколко други съставляват несвързания слой, защото след като данните бъдат извлечени в DataSet, можем да работим с тези данни, независимо дали е установена връзка или не. Тоест след получаване на данни от базата данни приложението може да бъде прекъснато от източника на данни.

Днешната епоха на високи технологии и научни постижения диктува висок темп на развитие на всички индустрии и науки, което доведе до автоматизация на повечето области на съвременния живот. Както всеки процес, автоматизацията има както положителни, така и отрицателни страни. Ще разгледаме един от тези аспекти, а именно дали автоматизацията опростява работните дейности на хората, по-подробно в бъдеще. От гледна точка на всеки мениджър, автоматизацията намалява производствените разходи и повишава ефективността на цялата организация като цяло. Но от гледна точка на хората, които разработват системи за автоматизация, ситуацията е доста сложна, тъй като основата на всяка информационна система е база данни или по-скоро СУБД. И изборът на една или друга СУБД ще повлияе върху по-нататъшната функционалност на информационната система и как ще бъде проектирана. И днес има около две дузини различни СУБД. И разработчикът е изправен пред труден избор коя СУБД да използва. А познаването на дизайнерските характеристики на всяка СУБД е непосилна задача дори за цял отдел за разработка.

Ситуацията става още по-лоша, когато е необходимо да се осигури поддръжка за различни източници на данни. Освен това всеки от тези източници на данни може да съхранява и обработва данни по свой собствен начин. Също така е необходимо да се вземе предвид, че различните езици за програмиране имат различна поддръжка за работа с една или друга СУБД.

Това означава, че все още има проблем с несъответствието между обработката на информация от повечето СУБД и начина, по който информацията се обработва от различни езици за програмиране.

Решението на тези проблеми беше намерено в новата технология ADO.NET, разработена от Microsoft и включена в новата им .NET Framework.

Цели и задачи

Всички дизайнери на информационни системи са обект на един голям проблем: сложността на избора на СУБД и по-нататъшното внедряване на взаимодействие с нея. В тази връзка целта на тази работа е да опрости процеса на проектиране на IC. За постигането на тази цел беше поставена задачата - да се разработи архитектура, която има способността да се мащабира и адаптира към всеки източник на данни. Архитектурата трябва да е лесна за разбиране за разработчиците на ИС и да има гъвкав механизъм за използване на ресурсите. За внедряването на тази система се предлага да се използва технологията ADO.NET и платформата .NET.

ADO.NET

ADO.NET е част от Microsoft .NET Framework, т.е. набор от инструменти и слоеве, които позволяват на приложението лесно да управлява и взаимодейства със своето файлово или сървърно базирано хранилище на данни.

В NET Framework библиотеката ADO.NET се намира в пространството на имената System.Data. Тези библиотеки осигуряват връзка с източници на данни, изпълнение на команди, както и съхранение, обработка и извличане на данни (Фигура 1.2).

ADO.NET се различава от предишните технологии за достъп до данни по това, че ви позволява да взаимодействате с базата данни офлайн, като използвате кеша за данни на базата данни.

Офлайн достъпът до данни е необходим, когато не е възможно да се поддържа отворена физическата връзка на всеки отделен потребител или обект към базата данни.

Важен елемент от офлайн достъпа до данни е контейнерът за таблични данни, който не познава СУБД. Този самостоятелен контейнер за таблични данни, поддържащ СУБД, е представен в библиотеките на ADO.NET чрез класа DataSet или DataTable.

Важно е обаче да запомните, че ADO.NET наследява предишната технология за достъп до данни, разработена от Microsoft, която се нарича класически ADO или просто ADO.

Въпреки че ADO.NET и ADO са напълно различни архитектури за достъп до данни.

ADO.NET обекти

Като всяка друга технология, ADO.NET се състои от няколко важни компонента. Всички .NET класове са групирани в пространства от имена. Всички свързани с ADO.NET функции са в пространството на имената System.Data. Освен това, като всеки друг .NET компонент, ADO.NET работи, не е изолиран и може да взаимодейства с различни други .NET компоненти.

Архитектурата на ADO.Net може да бъде разделена на две основни части: pluggable и standalone. Всички класове в ADO.NET могат да бъдат разделени според този критерий. Единственото изключение е класът DataAdapter, който посредничи между свързаните и несвързаните части на ADO.Net.

.NET доставчици на данни

Свързваемата част на ADO.Net е колекция от обекти за връзка.

Обектите за свързване са разделени в ADO.NET на специфични реализации за различни СУБД. Тоест за свързване към базата данни на SQL SERVER има специален клас SqlConnection.

Тези отделни реализации за конкретни СУБД се наричат ​​.NET доставчици на данни

С голямо разнообразие от налични източници на данни, ADO.NET трябва да може да поддържа множество източници на данни. Всеки такъв източник на данни може да има свои собствени характеристики или набор от възможности.

Следователно ADO.NET поддържа модела на доставчика. Доставчиците за конкретен източник на данни могат да бъдат определени като колекция от класове в едно пространство от имена, създадени специално за даден източник на данни. Тази функция е донякъде замъглена за OleDb, ODBC източници на данни, тъй като те по същество са проектирани да работят с всяка OLE и ODBC съвместима база данни.

Свързани класове и обекти.

Плъгин частта на ADO.NET има следните основни класове:

  • Връзка. Този клас ви позволява да установите връзка с източник на данни. (OleDbConnection, SqlConnection, OracleConnection)
  • Транзакция. Обект на транзакция (OleDbTransaction, SqlTransaction, OracleTransaction. ADO.NET има пространство от имена System.Transaction)
  • DataAdapter. Това е шлюз между офлайн и свързаните аспекти на ADO.NET. Той установява връзка и ако връзката вече е установена, съдържа достатъчно информация за приемане на данни от автономни обекти и взаимодействие с базата данни. (DataAdapter - SqlDataAdapter, OracleDataAdapter)
  • командване. Това е клас, представляващ изпълнима команда в основния източник на данни.
  • Параметър. Обект на командния параметър.
  • DataReader. Това е еквивалент на тръбопроводен курсор само за четене.

Поведение на обектите за връзка

Необходимостта от свързване към източник на данни е много важна за всяка архитектура за достъп до данни. ADO.NET ви позволява да се свържете с източник на данни, като използвате подходящ обект за връзка, който е включен в съответния доставчик на данни.

За да отворите връзка, трябва да посочите каква информация е необходима - като име на сървър, потребителско име, парола и др. Тъй като всеки целеви източник на връзка може да се нуждае от специфичен набор от информация, за да позволи на ADO.NET да се свърже с източника на данни, ние избрахме гъвкав механизъм за указване на всички параметри чрез низа за връзка.

Низът за връзка съдържа елементи с минималната информация, необходима за установяване на връзки, като последователност от двойки ключ-стойност. Могат да бъдат дефинирани различни двойки ключ-стойност в низа за свързване и някои конфигурируеми параметри определят поведението на връзката.

Самият обект за свързване на източник на данни наследява от класа DbConnection и получава готова логика, внедрена в базови класове.

Приложението трябва да споделя скъп ресурс - отворена връзка - и да го споделя с друг потребител. Именно за тези цели беше въведен пулът за свързване. По подразбиране групирането на връзки е активирано. Когато прави заявка, ADO.NET имплицитно проверява дали има налична неизползвана физическа връзка към базата данни. Ако има такава връзка, тя я използва. За да реши дали има такава физическа връзка или не, ADO.Net взема предвид натоварването на приложението и ако има твърде много едновременни заявки, ADO.Net може да поддържа няколко физически връзки отворени едновременно, тоест да увеличи брой връзки, ако е необходимо. Ако разгледаме снимката в детайли, ситуацията е следната:

Под класа DbConnection има брокер, който управлява набор от отворени връзки. Той е отговорен за увеличаване или намаляване на действителния брой отворени връзки в зависимост от нуждите на приложението. За клас брокер всяка заявена връзка се идентифицира уникално чрез съответния низ за връзка. Следователно, когато някое приложение на същото поиска отворена връзка, то първо разглежда вътрешния кеш на пула за връзки и ако има налична връзка в него, тогава тя се използва. Ако няма валидна връзка, се създава нова и се предава на приложението.

Вторият най-ресурсоемък обект в ADO.NET са транзакциите, които отговарят за коректността на промените в базата данни.

Транзакции

Транзакциите са набор от операции, които, за да се гарантира целостта и правилното поведение на системата, трябва да бъдат изпълнени успешно или неуспешно само всички заедно.

Транзакциите обикновено следват определени правила, известни като ACID свойства: Atomic, Consistent, Isolated и Durable.

Понякога по време на разработката на софтуер може да има ситуации, в които трябва да промените някои характеристики. По-специално, принципът на изолация може да бъде променен. И можете да контролирате неделимостта на транзакция, като използвате конструкции като вложени транзакции. Но човек трябва да се отклони от тези признаци само след внимателен анализ.

ADO.NET прилага мощен механизъм за поддържане на транзакции в базата данни. Самият ADO.NET поддържа транзакции с единична база данни, които се проследяват въз основа на връзки. Но може да използва пространството от имена System.Transactions за извършване на транзакции между бази данни или транзакции на мениджър на кръстосани ресурси.

В ADO.NET класът на връзка се използва просто за стартиране на транзакция.

Всички управлявани от NET доставчици, налични в NET Framework OleDb, SqlClient, OracleClient, ODBC, имат свои собствени реализации на клас транзакции.

Всички тези класове имплементират интерфейса IDbTransaction от пространството на имената System.Data.

Ако дадена транзакция не бъде върната назад, когато възникне грешка, тогава самата среда ще извика метода Rollback, но ще направи това само когато съответната физическа връзка бъде затворена или използвана повторно.

Трябва да се направи връзка с базата данни, преди да се извика методът BeginTransaction на класа Connection. Тъй като в този случай физическият ресурс за връзка се използва по-малко, което намалява натоварването на СУБД.

Основната полза от транзакциите е ефективността. За единични или кратки операции транзакциите може да са по-бавни, но за големи набори от данни те са по-бързи.

Нивата на изолация се използват за гъвкав контрол на поведението на транзакциите.

Нивата на изолация са степента, до която промените, направени извън транзакцията, са видими в рамките на транзакцията. Те определят колко чувствителна е една транзакция към промените, направени от други транзакции.

Например, ако две транзакции се изпълняват в SQL Server, независимо една от друга, тогава по подразбиране записите, вмъкнати от една транзакция, не се виждат в другата, докато първата транзакция не бъде ангажирана.

Концепцията за нивата на изолация е тясно свързана с концепцията за заключвания: чрез определяне на нивото на изолация на транзакция, ние получаваме информация за това колко дълго тази транзакция ще заключва други ресурси, за да ги защити от промени, които могат да бъдат направени от други операции.

Може да искате поведението на транзакцията да бъде така, че втора транзакция да може да види записите, вмъкнати от първата. В този случай е възможна следната ситуация:

  1. Неправилно извличане на данни, наречено "мръсно четене"
  2. „Невъзпроизводимо четене“ е състояние, когато транзакция, която преди е работила с данни, се опитва да взаимодейства с тези данни отново, но между тези взаимодействия друга транзакция е направила промени в данните, докато първата транзакция вече работи с данни от ниско ниво .
  3. „Фантомни редове“ – нека транзакция A работи с набор от 100 реда, избрани според определени критерии, и транзакция. B променя данните, в резултат на което, когато транзакция A ги избира отново, тя вече има различен набор от редове.

В ADO.NET нивата на транзакция са описани в изброяването IsolationLevel:

  • Хаос.Записите за промяна на чакащи транзакции с по-високи нива на изолация не могат да бъдат презаписани. Тази опция не се поддържа в SQL Server и Oracle
  • ReadUncommitted.Мръсното четене е разрешено. Пример за използване: наблюдение на системата от администратор.
  • ReadCommitted.Докато транзакцията чете данните, това избягва "мръсни четения", но в резултат на това може да се появят "невъзпроизводими четения". " може да възникне. Това ниво на изолация се поддържа в Oracle и SLQ Server.
  • RepeatableRead.В този случай споделените ключалки се поставят върху всички данни, използвани в предиката на заявката (критерии). Това не позволява други транзакции да променят данните и да причинят невъзпроизводими показания. Възможни са обаче и фантомни низове. Това ниво на изолация не се поддържа в Oracle.
  • Моментална снимка.Това ниво на изолация намалява шанса за заключване на ред, като поддържа копие на данните, които едно приложение може да прочете, докато друго променя същите данни.
  • Може да се сериализира.В този случай данните се заключват, което не позволява на другите да актуализират или вмъкват редове в DataSet, докато транзакцията не завърши. Тази ключалка може да бъде поставена на ред, страница или таблица. Това ниво на изолация се поддържа в Oracle

Отмяната на транзакция отменя ефекта от всяка операция в транзакцията. В някои случаи не е необходимо да се отменят всички операции - това означава, че е необходим механизъм за връщане назад само за част от транзакцията. Това може да се осъществи чрез "запазване на точки".

Точките за връщане назад са маркери, които действат като отметки. Докато транзакцията е в ход, можете да поставите точка и след това да се върнете обратно към тази точка, вместо напълно да върнете назад цялата транзакция. За тези цели методът Save е предоставен в обекта на транзакция. Но трябва да се отбележи, че този метод е достъпен само за връзки към SQL SERVER. Доставчикът на Oracle не поддържа точки за запис, но те винаги могат да бъдат внедрени чрез директни заявки или използване на съхранени процедури.

Но има няколко неща, които правят точките за запазване не много удобни. Един от тях е, че е необходимо да се извикат методите на Commit Rollback, когато транзакцията се върне обратно към една от точките за запис. Друго нещо, на което си струва да се обърне внимание, е, че след връщане на транзакция до определена точка, всички точки на неуспех, разположени извън текущата, се губят. И ако възникне нужда от тях, ще трябва да се монтират отново.

За да обобщим, оказва се, че точките за връщане назад ви позволяват да организирате връщане назад на транзакция под формата на последователност от действия, за всяко от които можете да извършвате отделни връщания назад. А вложените транзакции правят възможно организирането на йерархия от такива действия. При вложените транзакции една транзакция включва една или повече други транзакции. Но вложените транзакции са достъпни само за обекти за връзка от тип OleDb.

При работа с разнородни данни се използват разпределени транзакции – това са транзакции, които обхващат множество ресурси.

Разпределените транзакции могат да имат блокове, наречени мениджъри на ресурси (RM). Но в допълнение към тези диспечери е необходимо приложение, което ги слуша и координира действията им. Нарича се координатор на разпределени транзакции (DTC) или мениджър на транзакции.

Координаторът на транзакции, който се въвежда с Windows, се нарича Microsoft Distributed Transaction Coordinator (MSDTC) и е услуга на Windows, която извършва координация на транзакции за разпределени транзакции.

Типичното изпълнение на разпределена транзакция се състои от следните стъпки:

  • Приложението започва транзакцията, като я изисква от MSDTC. Това приложение обикновено се нарича инициатор.
  • След това приложението иска от RM да свърши работата си като част от тази транзакция, а мениджърите на ресурси се регистрират в мениджъра на транзакциите като част от същата транзакция. Това обикновено се нарича включване и влизане в сделка.
  • Ако всичко е наред, тогава приложението извършва транзакцията.
  • Ако нещо се обърка, всяка стъпка може да бъде върната назад.
  • И в двата случая координаторът на транзакциите координира работата на всички RM, за да гарантира, че или всички те успяват и извършват желаната работа, или всички анулират резултатите от работата си.

Когато се работи с разпределени транзакции, различните RM трябва да прилагат надежден протокол за ангажиране: най-често срещаното изпълнение на такъв протокол се нарича двуфазово ангажиране.

За да обобщим, ADO.NET има добра поддръжка за транзакции, но те не винаги са необходими за използване. Тъй като използването на транзакции е допълнително натоварване на системата. Освен това транзакциите могат да заключат някои редове на таблицата, което пряко влияе върху производителността. Това е особено забележимо при използване на MSDTC.

Автономни класове и обекти

Свързаните приложения сами по себе си не отговарят на всички изисквания за днешните разпределени приложения. Самостоятелните приложения, създадени с ADO.NET, имат различен подход. Но за да се осигури автономност, се използват обекти DataAdapter. Те изпълняват заявки, използвайки обекти за връзка. И резултатите от изпълнението, тоест данните, се прехвърлят към автономни обекти. Благодарение на този принцип автономните обекти не знаят за съществуването на обекти за връзка, тъй като не работят директно с тях. Тоест внедряването на обект, съхраняващ данни, не трябва да зависи от конкретен доставчик на данни, а именно СУБД. Тъй като конкретното внедряване на адаптер за данни зависи от съответния източник на данни, конкретни адаптери за данни се внедряват в конкретни доставчици.

Самостоятелните приложения обикновено се свързват с базата данни възможно най-късно и прекъсват връзката възможно най-рано. Важен елемент в такава схема за свързване и осигуряване на автономен достъп до данни е контейнер за таблични данни, който не познава СУБД. Този самостоятелен контейнер за таблични данни, поддържащ СУБД, е представен в библиотеките на ADO.NET чрез класа DataSet или DataTable.

Когато работи в самостоятелен режим, ADO.NET поддържа набор от действителни физически връзки за различни заявки, като по този начин увеличава ефективността на ресурсите за връзка.

Има няколко основни класа на самостоятелния модел на ADO.NET:

  • DataSet. Класът DataSet е ядрото на самостоятелния достъп до данни в ADO.NET. Най-добре е да мислите за него така, сякаш има собствена малка СУБД, изцяло в паметта.
  • Таблица с данни. Преди всичко този клас е подобен на таблица на база данни. Състои се от обекти DataColumn и DataRow, които са редове и колони.
  • DataView. Това е обект за изгледи на база данни.
  • DataRelation. Този клас ви позволява да дефинирате релации между различни таблици, които могат да се използват за проверка на съгласуваността на данните от различни таблици.

Заключение

Технологията ADO.NET е напълно в състояние да осигури механизъм за достъп до всеки източник на данни, като по този начин предоставя на разработчика мощен механизъм за взаимодействие с бази данни, който може напълно да реализира всички нужди, които възникват при проектирането на ИС.

Технологии ADO .NET, . NET FrameWork, CORBA

Технологията за отдалечен достъп до база данни ADO .NET също беше разработена за архитектурата клиент-сървър. В допълнение към двете нива на отдалечени бази данни - клиент и сървър - се появяват допълнителни нива - бизнес логически сървъри, които реализират бизнес логиката на приложенията.

Технологията ADO .NET установява следната схема за работа на клиента със сървъра на базата данни:

Установяване на връзка със сървъра;

Получаване на необходимите данни;

Закриване на връзката;

Обработка на данни;

Установяване на връзка за прехвърляне на променените данни обратно към сървъра.

ADO .NET се базира на два основни модула:

Доставчик на данни .NET FrameWork

Жилищна релационна база данни (DataSet).

Доставчик на данни, както подсказва името му, отговаря за комуникацията на приложението с източника на данни и за манипулирането на данните. Доставчикът на данни включва следните обекти за манипулиране на данни:

a) Връзката се използва за установяване на връзка с източник на данни, както и за управление на транзакции.

b) Командата ви позволява да манипулирате изходни данни, както и да изпълнявате съхранени процедури. В този случай параметрите могат да се използват за прехвърляне на данни и в двете посоки.

c) DataAdapter служи като връзка между резидентната база данни DataSet и източника на данни и обикновено използва обекта Command за изпълнение на SQL команди както при попълване на DataSet с данни, така и при прехвърляне обратно на данни, модифицирани от клиента, към източника. Той има четири метода за изпълнение на тези функции: SelectCommand, InsertCommand, UpdateCommand и DeleteCommand.

d) DataReader предоставя данни само за четене от източника. Ако клиентското приложение не модифицира данни и не изисква произволно извличане на данни, а само еднократното им преглеждане е достатъчно, тогава използването на DataReader вместо DataSet ще спести компютърни ресурси и също ще подобри производителността на приложението.

Жилищна релационна база данни е релационна база данни, получена от клиента, която се съхранява в неговата резидентна RAM.

След това клиентът в офлайн режим обработва данните и, ако е необходимо, ги модифицира, след което отново се установява връзка със сървъра и модифицираната информация от резидентната база данни се прехвърля обратно.

Тази схема на взаимодействие е донякъде подобна на това как работи файловата архитектура -

сървър и често се използва от предприятията при работа с отдалечени бази данни чрез глобалния интернет.

За да осигури достъп до обекти през глобалния интернет, ADO .NET включи модула .NET FrameWork, който осигурява взаимодействие между различни формати за представяне на данни, включително HTML и XML.

От тези характеристики става ясно, че технологията ADO .NET осигурява:

Възможност за взаимодействие между данни от различни формати, включително HTML и XML;

Значително намаляване на разходите при работа с отдалечени бази данни през Интернет.

Общ преглед на ADO.NET

ADO.NET- нещо повече от добавка към съществуващ API. Сходството с ADO е минимално; класовете и методите за достъп до данни се различават значително.

ADO (обекти с данни ActiveX)е библиотека от COM компоненти, която получи много превъплъщения през последните няколко години. ADO се състои предимно от обекти Connection, Command, Recordset и Field. С помощта на ADO се отваря връзка с базата данни, след което някои данни се извличат и поставят в набор от записи, състоящ се от полета; тези данни след това се манипулират и актуализират на сървъра, след което връзката се затваря. Освен това ADO предлага т.нар прекъснат набор от записи, който се използва, когато не е желателно връзката с базата да се държи отворена за дълго време.

Има няколко проблема, които ADO не решава задоволително. Най-забележимият от тях е обемът (по отношение на физическия размер) на деактивиран набор от записи. Нуждата от този инструмент нараства с развитието на уеб базираните изчисления, така че в този случай беше необходим нов подход. Преходът от ADO към ADO.NET не трябва да бъде твърде труден, тъй като все още има някои прилики между технологиите.

Освен това, ако използвате SQL Server, има чудесен набор от управлявани класове, които са настроени да осигурят максимална производителност на базата данни. Само това е достатъчно за преминаване към ADO.NET.

ADO.NET идва с три клиентски пространства на бази данни: едно за SQL сървър, друго за източници на данни Отворена връзка с база данни (ODBC)и трето за всяка база данни, достъпна чрез OLE DB. Ако е избрана база данни, различна от SQL Server, изберете OLE DB, освен ако нямате друг избор освен ODBC. Ако използвате Oracle като ваша база данни, можете да посетите сайта на Oracle .NET Developer и да получите техния .NET доставчик - ODP.NET на www.oracle.com/technology/tech/windows/odpnet/index.html.

От гледна точка на програмист, тялото на ADO.NET се състои от базов сбор, наречен System.Data.dll. Този двоичен файл съдържа значителен брой пространства от имена, много от които представляват типове, специфични за доставчика на данни ADO.NET:

Повечето шаблони за проекти на Visual Studio 2010 автоматично препращат към тази ключова библиотека за достъп до данни. Въпреки това, за да импортирате желаните пространства от имена, трябва да промените кодовите файлове, например:

Използване на системата; използване на System.Data; използване на System.Data.SqlClient; ...

Моля, имайте предвид също, че в допълнение към System.Data.dll има и други ADO.NET-ориентирани сборки (напр. System.Data.OracleClient.dllИ System.Data.Entity.dll), които трябва да бъдат посочени ръчно в текущия проект с помощта на диалоговия прозорец Добавяне на препратка.

Трите страни на ADO.NET

Библиотеките на ADO.NET могат да се използват по три концептуално различни начина: онлайн, офлайн и чрез технологията Entity Framework. Използвайки свързан слой, кодовата база изрично се свързва със и прекъсва връзката със съответното хранилище на данни. Когато използвате ADO.NET по този начин, вие обикновено взаимодействате с хранилището на данни, като използвате обекти за връзка, командни обекти и обекти за четене на данни.

Прекъснат слой, ви позволява да работите с набор от обекти DataTable (съдържащи се в DataSet), който представлява клиентско копие на външни данни. Когато получите DataSet с помощта на съответния обект на адаптер за данни, връзката се отваря и затваря автоматично. Ясно е, че този подход помага за бързо освобождаване на връзки за други повиквания и увеличава мащабируемостта на системите.

ADO.NET използва многослойна архитектура, която се върти около малък брой ключови концепции, като обекти Connection, Command и DataSet. Архитектурата на ADO.NET обаче е доста различна от класическата архитектура на ADO.

Доставчици на данни в ADO.NET

Доставчик на данние набор от ADO.NET класове, които ви позволяват да получите достъп до конкретна база данни, да изпълнявате SQL команди и да извличате данни. По същество доставчикът на данни е мост между вашето приложение и източника на данни.

Като първо приближение доставчикът на данни може да се разглежда като набор от типове, дефинирани в дадено пространство от имена, които са предназначени да взаимодействат с конкретен източник на данни. Въпреки това, независимо от използвания доставчик на данни, всеки дефинира набор от класове, които осигуряват основна функционалност. Таблицата по-долу показва някои общи основни обекти, техните базови класове (дефинирани в пространството от имена System.Data.Common) и основните интерфейси (дефинирани в пространството от имена System.Data), които те прилагат:

Основни ADO.NET обекти на доставчик на данни
Тип обект Базов клас Съответстващи интерфейси Предназначение
Връзка DbConnection IDbConnection Позволява ви да се свързвате и изключвате от хранилището за данни. Освен това обектите за свързване осигуряват достъп до съответните обекти на транзакция
командване DbCommand IDbCommand Представлява SQL заявка или съхранена процедура. Освен това командните обекти осигуряват достъп до обект за четене на данни, специфичен за доставчика на данни
DataReader DbDataReader IDataReader, IDataRecord Осигурява достъп само за четене до данни в посока напред, като използва курсор от страната на сървъра
DataAdapter DbDataAdapter IDataAdapter, IDbDataAdapter Изпраща набори от данни от хранилището на данни към извикващия процес и обратно. Адаптерите за данни съдържат връзка и набор от четири вътрешни командни обекта за извличане, вмъкване, модифициране и изтриване на информация в хранилището на данни
Параметър DbПараметър IDataParameter, IDbDataParameter Представлява именуван параметър в параметризирана заявка
Транзакция DbTransaction IDbTransaction Капсулира транзакция в база данни

Конкретните имена на тези базови класове варират между доставчиците (например SqlConnection, OracleConnection, OdbcConnection и MySqlConnection), но всички тези обекти са извлечени от един и същ базов клас (в случай на обекти за връзка, това е DbConnection), който имплементира идентични интерфейси (като IDbConnection) . Следователно, ако се научите да работите с един доставчик на данни, можете лесно да се справите с останалите.

В ADO.NET терминът "обект за свързване" всъщност се отнася до специфичен тип, извлечен от DbConnection; няма обект за свързване „изобщо“. Същото може да се каже за "обект на команда", "обект на адаптер за данни" и т.н. По конвенция имената на обекти в определен доставчик на данни са с префикс от съответната СУБД (например SqlConnection, OracleConnection, SqlDataReader и т.н.).

Една от ключовите идеи зад модела на доставчик на ADO.NET е разширяемостта. С други думи, разработчиците могат да създават свои собствени доставчици за собствени източници на данни. Всъщност има много поддържащи примери, които демонстрират как да създадете персонализирани ADO.NET доставчици, които служат като обвивки за нерелационни хранилища на данни, като например файлова система или директория. Някои доставчици на трети страни също продават свои собствени доставчици на данни за .NET.

.NET Framework идва с малък набор от четири доставчика:

SQL сървър

Осигурява оптимизиран достъп до бази данни на SQL Server (версия 7.0 и по-нова).

OLE DB

Осигурява достъп до всеки източник на данни, който има OLE DB драйвер. Това включва версии на бази данни на SQL Server, по-стари от 7.0.

Оракул

Осигурява оптимизиран достъп до бази данни на Oracle (версия 8i и по-нова).

ODBC

Осигурява достъп до всеки източник на данни, който има ODBC драйвер.

Доставчикът на Oracle е отхвърлен в .NET 4. Въпреки че все още работи, Microsoft препоръчва вместо това да използвате доставчик на трета страна като ODP.NET (Oracle Data Provider for .NET) за достъп до бази данни на Oracle, който е достъпен на http:/ /www.oracle.com. Този доставчик предоставя обширна поддръжка за специализирани типове данни на Oracle като LOB, времеви клейма и XML данни, както и няколко допълнителни функции.

Фигурата по-долу показва слоевете на модела на доставчик на ADO.NET:

Когато избирате доставчик, първо се опитайте да намерите вграден .NET доставчик, който е насочен към вашия съществуващ източник на данни. Ако такъв не бъде намерен, можете да използвате OLE DB, ако имате OLE DB драйвер за източника на данни.

OLE DB технологията съществува от много години като част от ADO, така че повечето източници на данни имат OLE DB драйвери (включително SQL Server, Oracle, Access, MySQL и много други). В редките случаи, когато не можете да намерите специализиран .NET доставчик или OLE DB драйвер, можете да използвате ODBC доставчик, който работи във връзка с ODBC драйвера.

Стандартизация в ADO.NET

На пръв поглед може да изглежда, че ADO.NET предлага фрагментиран модел, тъй като не включва общ набор от обекти, които работят с множество типове бази данни. В резултат на това, когато преминавате от една релационна СУБД към друга, трябва да промените кода за достъп до данни, за да използвате различен набор от класове.

Но въпреки че различните доставчици на .NET данни използват различни класове, всички те са стандартизирани по някакъв начин. По-точно, всеки доставчик е базиран на един и същ набор от интерфейси и базови класове. Например, обектът Connection имплементира интерфейса IDbConnection, който дефинира ключови методи като Open() и Close(). Тази стандартизация гарантира, че всеки клас Connection работи по един и същи начин и излага същия набор от ключови свойства и методи.

Зад кулисите различните доставчици използват напълно различни повиквания и API на ниско ниво. Например доставчикът на данни на SQL Server използва патентован протокол TDS (Tabular Data Stream - табличен поток от данни)за взаимодействие със сървъра. Предимствата на този модел не са очевидни веднага, но са доста значителни:

    Тъй като всеки доставчик използва едни и същи интерфейси и базови класове, можете да напишете общ код за достъп до данни (с малко допълнителни усилия), като работите с интерфейси, а не с класове на доставчик.

    Тъй като всеки доставчик се внедрява отделно, той може да използва подходящи оптимизации (това е различно от ADO модела, където всяко извикване на база данни трябва да премине през общия слой, преди да достигне основния драйвер на базата данни). Освен това специализираните доставчици могат да добавят нестандартни функции, които другите доставчици нямат (например способността на SQL Sever да изпълнява XML заявки).

ADO.NET има и друго ниво на стандартизация - DataSet. Класът DataSet е контейнер с общо предназначение на данни, който се извлича от една или повече таблици с източници на данни. DataSet е напълно общ; с други думи, специализираните доставчици не дефинират свои собствени специализирани версии на класа DataSet.

Независимо кой доставчик на данни използвате, можете да извлечете данни и да ги поставите в напълно самостоятелен набор от данни по същия начин. Това улеснява отделянето на кода, който извлича данните от кода, който ги обработва. Ако основната база данни се промени, ще трябва да се промени само кодът, който извлича данните, но ако използвате DataSet и информацията има същата структура, няма да е необходимо да променяте начина, по който се обработва.

ADO.NET фундаментални класове

ADO.NET класовете са групирани в няколко пространства от имена. Всеки доставчик има свое собствено пространство от имена и общи класове като DataSet са в пространството от имена System.Data. Най-важните пространства от имена за основна поддръжка на ADO.NET са описани по-долу:

System.Data

Съдържа ключови класове контейнери за данни, които моделират колони, релации, таблици, набори от данни, редове, изгледи и ограничения. Освен това съдържа ключови интерфейси, които се изпълняват от обекти с данни, базирани на връзка

System.Data.Common

Съдържа основните, най-абстрактни класове, които имплементират някои от интерфейсите от System.Data и дефинират основната функционалност на ADO.NET. Доставчиците на данни наследяват тези класове (DbConnection, DbCommand и т.н.), създавайки свои собствени специализирани версии

System.Data.OleDb

Съдържа класове, използвани за свързване към доставчик на OLE DB, включително OleDbCommand, OleDbConnection и OleDbDataAdapter. Тези класове поддържат повечето OLE DB доставчици, но не и тези, които изискват OLE DB интерфейси версия 2.5

System.Data.SqlClient

Съдържа класове, използвани за свързване към база данни на Microsoft SQL Server, включително SqlDbCommand, SqlDbConnection и SqlDbDataAdapter. Тези класове са оптимизирани да използват TDS интерфейса към SQL Server

System.Data.OracleClient

Съдържа класовете, необходими за свързване към база данни на Oracle (версия 8.1.7 и по-нова), включително OracleCommand, OracleConnection и OracleDataAdapter. Тези класове използват оптимизиран интерфейс OCI (Oracle Call Interface)

System.Data.Odbc

Съдържа класове, необходими за свързване към повечето ODBC драйвери, като OdbcCommand, OdbcConnection, OdbcDataReader и OdbcDataAdapter. ODBC драйверите се предоставят за всички типове източници на данни и се конфигурират чрез иконата Източници на данни в контролния панел

System.Data.SqlTypes

Съдържа структури, които съответстват на вградените в SQL Server типове данни. Тези класове не са необходими, но предоставят алтернатива на използването на стандартни .NET типове данни, които изискват автоматично преобразуване