Резюме
В этой главе рассмотрен объект 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), может привести к блокировке записей на несколько десятков секунд или даже минут.
Второй способ — оптимистическая блокировка (или оптимистическое управление параллельностью) — основан на очень кратковременной блокировке записей во время их фактического обновления. Этот способ решает проблему управления блокировками и масштабируемости, а также прекрасно подходит для редактирования наборов данных, отключенных от базы данных. Но что произойдет, если пользователь Б захочет обновить данные, уже обновленные пользователем А? Один из вариантов решения этой проблемы основан на признании только последнего обновления. Однако этот способ годится только для ограниченного круга приложений.
Для использования оптимистической блокировки нужно определить, изменялись ли данные после их последнего извлечения, что называется нарушением параллельного доступа (concurrency violation). Для этого применяются две основные стратегии.