Обработка баз данных на Visual Basic®.NET

В этой главе рассмотрен объект DataAdapter, который является одним из основных объектов модели ADO.NET. Он играет роль моста между неподключенными объектами DataSet (и связанными с ними объектами) и подключенными объектами DataProvider, которые фактически связаны и подключены к физическому источнику данных.

Объект DataAdapter используется для вставки данных в объект DataSet из источника данных с помощью явно заданных команд или хранимых процедур. Объект DataAdapter также автоматически обновляет источник данных теми изменениями, которые произошли в объекте DataSet, что позволяет полностью настроить команды вставки, обновления и удаления для источника данных.

Вопросы и ответы

Иногда требуется программно создать и вставить в набор несколько записей, а затем внести эти обновления в базу данных. В модели ADO 2.X можно создать набор записей, но нельзя обновить базу данных. А как обстоит дело в модели ADO.NET?

В модели ADO.NET это требование реализуется очень просто. Как отмечалось в главе 5, "ADO.NET: объект DataSet", объект DataSet является контейнером данных, который не зависит от фактически используемого источника данных. Для обновления базы данных изменениями из объекта DataSet достаточно только подключиться к уже сконфигурированному объекту DataAdapter и вызвать его метод Update, который фактически обновит базу данных. Это верно и для программно созданных объектов DataSet, а не только для созданных с помощью команды Select объектов DataAdapter. В момент готовности к внесению изменений в физический источник данных достаточно подключиться к сконфигурированному объекту DataAdapter и вызвать его метод Update.

ГЛАВА 7 ADO.NET: дополнительные компоненты

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

Обнаружение конфликтов при параллельном доступе к данным

Разработчики, имеющие опыт создания многопользовательских баз данных, знают о потенциальных проблемах при параллельном доступе к данным, возникающих при попытке одновременного обновления одних и тех же данных со стороны нескольких пользователей. Допустим, что пользователь А считывает какие-то данные и пользователь Б считывает те же данные, затем пользователь А изменяет эти данные, а пользователь Б также пытается их изменить. Как можно решить эту проблему? Существует два основных способа решения конфликтных ситуаций при параллельном доступе к данным.

Первый способ — пессимистическая блокировка (или пессимистическое управление параллельностью) — решает проблему перезаписи пользователем Б изменений, внесенных пользователем А. Для этого после считывания данных пользователем А для их редактирования на эти данные накладывается блокировка. Эта блокировка запрещает доступ к данным со стороны других пользователей до тех пор, пока пользователь А не завершит работу с заблокированными данными и не снимет блокировку.

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

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

Второй способ — оптимистическая блокировка (или оптимистическое управление параллельностью) — основан на очень кратковременной блокировке записей во время их фактического обновления. Этот способ решает проблему управления блокировками и масштабируемости, а также прекрасно подходит для редактирования наборов данных, отключенных от базы данных. Но что произойдет, если пользователь Б захочет обновить данные, уже обновленные пользователем А? Один из вариантов решения этой проблемы основан на признании только последнего обновления. Однако этот способ годится только для ограниченного круга приложений.