До сих пір у всіх розглянутих прикладах використовувалися кошти ADO.NET, засновані на з'єднаннях. Коли застосовується цей підхід, дані виключають будь-які операції з ними в сховище в момент їх вилучення. Ваш код повністю відстежує всі дії користувача, зберігання інформації і визначення того, коли нова команда повинна бути згенерована і виконана.
Природно, це рішення не позбавлене недоліків, таких як наслідки паралелізму. Залежно від того, як спроектовано додаток, загальний пакет змін може бути відправлений негайно. Але єдина помилка (на кшталт спроби оновити запис, яку одночасно оновлює інший користувач) може зруйнувати весь процес оновлення. При добре продуманому кодуванні можна захистити свій додаток від цих проблем, проте будуть потрібні додаткові зусилля.
З іншого боку, іноді може знадобитися використовувати автономну (disconnected) модель доступу ADO.NET і DataSet. Нижче перераховані сценарії, в яких DataSet використовувати легше, ніж DataReader:
Коли потрібен зручний пакет для відправки даних іншого компонента (наприклад, якщо ви поділяєте інформацію з іншими компонентами або ставите їх клієнтам через веб-службу).
Коли потрібен зручний формат файлу для сериализации даних на диск (об'єкт DataSet включає вбудовану функціональність, що дозволяє зберігати його в файл XML).
Коли потрібно організувати навігацію в двох напрямках по великому обсягу даних. Наприклад, ви можете використовувати DataSet для підтримки спискового елементу управління з розбивкою на сторінки, який відображає інформацію по частинах. На противагу цьому DataReader забезпечує переміщення тільки в одному напрямку - вперед.
Коли потрібно виконувати навігацію по декількох різних таблиць. Об'єкт DataSet може зберегти в собі всі ці таблиці і інформацію про відносини між ними, дозволяючи створювати сторінки "головна-детальна" без необхідності запиту до бази даних більш ніж один раз.
Коли потрібно використовувати прив'язку даних до елементів управління користувальницького інтерфейсу. Для прив'язки даних можна застосовувати і DataReader, але оскільки DataReader використовує лише односпрямований курсор, неможливо прив'язати дані до безлічі елементів управління. Крім того, на відміну від DataSet, він не має можливості застосовувати призначені для користувача критерії сортування та фільтрації.
Коли даними необхідно маніпулювати як XML-розміткою.
Там, де необхідно забезпечувати пакетні поновлення. Наприклад, можна створити веб-службу, яка дозволяє клієнту завантажувати DataTable, заповнений рядками, виконувати в ньому множинні зміни і пізніше відправляти їх джерела даних. В такий момент веб-служба може проводити всі зміни в єдиній операції (якщо припустити, що ніяких конфліктів не виявлено).
Веб-додатки та DataSet
Загальна помилка полягає в тому, що об'єкт DataSet необхідний для забезпечення масштабованості веб-додатки. Тепер, коли ви розумієте архітектуру обробки запитів ASP.NET, можливо, ви бачите, що це не зовсім так. Веб-додатки виконуються протягом якихось секунд, а це значить, що навіть якщо веб-додаток використовує прямий доступ на основі курсорів, час життя з'єднання настільки коротко, що не може сильно вплинути на масштабованість, крім як для дуже сильно навантажених веб- додатків.
Фактично, застосування DataSet набагато більш виправдано в розподілених додатках з багатофункціональними Windows-клієнтами. У такому сценарії клієнти можуть отримувати DataSet з сервера (можливо, через веб-службу), працювати з цими об'єктами DataSet протягом тривалого часу і повторно підключатися до системи тільки в тому випадку, якщо вони потребують оновлення джерела даних проведеними змінами. Це дозволяє системі обслуговувати набагато більшу кількість одночасно працюючих користувачів, ніж у випадку, коли кожен клієнт підтримує пряме, які тривалий час існуючий обліковий запис. Це також дозволяє ефективно розділяти ресурси за рахунок кешування даних на сервері і використовувати пули сполук між клієнтськими запитами.
Об'єкт DataSet також виступає в ролі чистого пакета інформації для багатофункціональних клієнтських додатків, які лише час від часу підключаються до системи.
Наприклад, розглянемо туристичне агентство, з яким потрібно вводити інформацію про замовлення або переглядати інформацію про продажі путівок на портативному комп'ютері. Використовуючи DataSet, додаток на портативному комп'ютері користувача може зберігати автономні дані локально і серіалізіровать їх в XML-файл. Це дозволить торговому агенту складати нові замовлення, використовуючи кешовані дані, навіть коли підключення до Інтернету не є. Нові дані можуть бути відправлені пізніше, коли користувач зможе підключитися до системи.
Отже, що ж залишається веб-додатків ASP.NET? По суті, є два вибори. Можна використовувати об'єкт DataSet або застосовувати прямі команди, що виключають необхідність в DataSet. Говорячи загалом, коли необхідно додавати, вставляти або оновлювати записи, без DataSet можна обійтися. Однак повністю уникнути застосування DataSet не вдасться.
Під час вилучення записів, швидше за все, захочеться використовувати DataSet, тому що він підтримує набір абсолютно необхідних коштів. Зокрема, DataSet дозволяє легко передавати блок даних від компонента бази даних на веб-сторінку. Об'єкт DataSet також підтримує прив'язку даних, що дає можливість відображати інформацію в багатофункціональних елементах управління даними, таких як GridView. З цієї причини більшість веб-додатків витягають дані в DataSet, а поновлення виробляють через прямі команди.
Веб-служби являють собою єдиний реальний сценарій застосування веб-додатків, в якому може бути прийнято рішення проводити пакетне оновлення через DataSet. В цьому випадку багатофункціональне клієнтську програму завантажує дані в DataSet, редагує їх і пізніше відправляє DataSet для фіксації внесених змін.
Інтеграція з XML
Об'єкт DataSet також представляє вбудовану сериализацию в XML. Вам навіть не потрібно знати про це, щоб скористатися її перевагами на зразок можливості простий серілізаціі DataSet в файл або передачі DataSet іншому додатку через веб-службу. А найкраще те, що це засіб дозволяє спільно використовувати дані з клієнтами, написаними на інших мовах програмування і працюють під управлінням інших операційних систем. Однак реалізація такого рішення не проста (і часто DataSet - не найкращий підхід), оскільки є лише мінімальна можливість настройки структури XML-розмітки, яку виробляє DataSet.
Об'єкт DataSet - основа автономного доступу до даних. DataSet містить в собі два важливих інгредієнта: колекцію з нуля або більше таблиць (доступних через властивість Tables) і колекцію з нуля або більше відносин, які можна застосовувати для зв'язування таблиць між собою (представлених властивістю Relationships).
На малюнку нижче показана базова структура DataSet:
Іноді розробники-новачки в ADO.NET припускаються помилки, припускаючи, що DataSet повинен містити всю інформацію певної таблиці джерела даних. Це не так. З міркувань продуктивності зазвичай DataSet використовується для роботи з невеликим підмножиною від загального обсягу інформації джерела даних. До того ж таблиці в DataSet не зобов'язані відображатися безпосередньо на таблиці джерела даних. Одна таблиця може містити результати запиту по одній таблиці або ж результати запиту JOIN, який комбінує дані з більш ніж однієї пов'язаної таблиці.
Як видно на малюнку, кожен запис колекції DataSet.Tables - це DataTable. Об'єкт DataTable містить власні колекції - колекцію Columns об'єктів DataColumn (описують ім'я і тип даних кожного поля) і колекцію Rows об'єктів DataRow (що містять дійсні дані кожного запису).
Кожна Запис в DataTable представлена об'єктом DataRow. Кожен об'єкт DataRow представляє одиночну запис в таблиці, яка була витягнута з джерела даних. DataRow є контейнером для дійсних значень полів. Отримати доступ до них можна по імені поля, як у випадку myRow [ "FieldName"]. Завжди пам'ятайте, що дані в джерелі взагалі ніяк не зачіпаються, коли ви працюєте з об'єктами DataSet. Замість цього всі зміни проводяться локально в об'єкті DataSet, розташованому в пам'яті. DataSet ніколи не покладається на будь-яке з'єднання з джерелом даних.
Деякі методи класу DataSet