Обновление таблицы: легкий способ на основе перетаскивания мышью

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

1. Вначале создадим на локальном экземпляре на SQL Server 2005 базу данных с именем Test, а в ней создадим таблицу Animals; для этого выполним следующий сценарий:

Create Datanase Test GO

3SE Test GO

CREATE ТЛВ:,Е Animals (

AnimallD int N0T NULL,

Ar.imalName varchar(50) NOT N’JLL,

CONSTRAINT ?K_Animals PRIMARY КЕУ (AnimallD)

)

GO

2. После создания таблицы запустите Visual Studio и создайте приложение на базе Windciws-формы. Измените текст заголовка в главной форме на “Exercise 9.1″.
3. В Visual Studio выберите пункт Data^Add New Data Source (Данные1*Добавить новый источник данных). Как было описано в главе 7. добавьте новый источник данных для базы данных Tes t, доступ к которой осуществляется через локальный экземпляр SQL Server 2005. При появлении предложения выбрать объекты базы данных укажите таблицу Aniirals.

4. Вернитесь в окно Data Sourccs {выберите пункт Data=>Show Data Sources (Данные1^Показать источники данных}}, выберите таблицу Animals и укажите для нее опцию DataGndView.

5. И. наконец, перетащите таблицу Animals на главную форму приложения.
6. В элементе ammalsBindingNavigator установите свойство enabled кнопки Save (т.е. элемента bmdingNavigatorSaveltem) в true.

7. Скомпилируйте я запустите приложение. Добавьте несколько строк, как показано, а затем щелкните на кнопке Save. Теперь можно выполнить запрос Select * from Anima] s к локальной базе данных, чтобы убедиться, что результаты действительно сохранены в базе данных.

Что произошло? Как одна строка кода смогла выполнить столько работы? Для ответа на эти вопросы рассмотрим по одному автоматически добавленные объекты.
Чтобы увидеть все наглядно, выберите в IDE Visual Studio пункт Show All Files (Показать все файлы)
Первым добавленным объектом является testDataSet. Дважды щелкнув на нем, вы увидите, что он содержит два объекта: Animals типа DataTable и AnimalsTableAdapter типа TableAdapter- Если щелкнуть правой кнопкой на объекте AnimalsTableAdapter и выбрать пункт Configure (Конфигурировать).
В этом диалоговом окне можно указать оператор SELECT для заполнения объекта testDataSet во время выполнения. Но это еще не все: щелкнув на кнопке Advanced Options (Дополнительные опции), вы увидите диалоговое окно.
В окне Advanced Options представлены три возможности. Точное назначение этих трех возможностей станет ясным по мере чтения этой и следующей главы, а пока вам достаточно понять, что эти флажки позволяют:

• Указать, что нужен объект TableAdapter, позволяющий выполнять операторы INSERT, UPDATE и DELETE.

• Использовать оптимистичный уровень параллелизма.

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

Первый флажок понятен без объяснений: его установка позволяет использовать TableAdapter и обновлять исходный источник данных.
Второй и третий флажки относятся к автономной природе этого приложения и к обработке проблем, которые могут возникнуть в связи с параллелизмом. Например, пока вы заполняете DataSet, кто-то другой может изменить исходные данные. Нужно не только разрешать такие конфликты, возникающие из-за автономной природы объектов DataSec. но и обновлять автономный кэш данных (DataSet или DataTable), когда нужно вновь установить подключение к исходному источнику данных

Чтобы почувствовать автономную сущность этого приложения, удалите из источника данных все строки с помощью следующего SQL-запроса.

Теперь начнем еще раз с самого начала. Представьте себе ситуацию, когда два пользователя одновременно добавляют информацию в базу данных. Чтобы смоделировать зто, запустите два экземпляра приложения и добавите какие-нибудь данные. Заметьте, что на этом этане ни один из экземпляров приложения не сохранил свои данные.
Самые наблюдательные из вас могут заметить, что обо. пользователя используют одни и те же значения первичного ключа для вновь введенных строк. Зачем это сделано? Это сделано потому, что ни один из пользователей не знает, какие первичные ключи задействованы другим пользователем. Ведь оба пользователя полностью отключены от исходной базы данных, и их общий диспетчер — база данных ничего не сообщает им об используемых ключах. На этом этапе важно понять, что пользователи могут ввести данные неверно, но не сохранить их в силу автономности работы. С первого взгляда зто может показаться неправильным, но пока данные не записываются в базу данных, ничего страшного не происходит. Единственные изменения присутствуют лишь в локальных копиях хранящихся в памяти кэшей автономных данных (в нашем случае это DataTable). В базе данных все по-старому и без проблем.

Пользователи не могут знать нужных значений первичных ключей, т.к. центральная подключенная база данных не выполняет за них эту работу. Можно было бы использовать возможность постоянного подключения к центральной базе данных и блокировки строк, редактируемых отдельными пользователями, по как было показано, для этого пришлось бы держать подключение открытым — и, значит, существенно снизить производительность системы. Но кроме ведения пула подключений, реализация такой пессимистичной блокировки строк заставила бы других пользователей ожидать, когда один пользователь завершит ввод своих изменений. Бывают ситуации, когда это решение вполне возможно. Однако в большинстве случаев длительные блокировки уровня строки, страницы или таблицы не рекомендуются.

Пока мы не будем слишком углубляться в эту довольно интересную тему параллелизма, просто сохраните данные в левом приложении (сод и Cat), а затем попытайтесь сохранить данные в правом приложении (Horse и Mule) — но только после того, как Dcg и Cat сохранены левым приложением.
Это приложение четко сообщает, что обнаружено нарушение первичного ключа ?K_Animals.

Так что второй пользователь не может сохранить свои данные, не изменив ключи на правильные. Но как второй пользователь может узнать, какие ключи использовать, пока он не обновит данные?

Это можно выполнить, обновляя данные из источника данных после неудачной попытки обновления. Вообще-то имеет смысл обновлять данные из исходного источника. даже если обновление прошло успешно, т.к. пользователю может понадобиться добавить следующие строки или изменить существующие строки — в том числе и введенные другим пользователем. Кроме того, обновление данных даст пользователю свежий снимок данных, в том числе и последний сгенерированный первичный ключ, так что вероятность ввода неверного автономно сгенерированного первичного ключа в DataTable снижается, и вы не получите исключения и необходимость еще одного обновления.

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

Related posts:

Посредник между подключенным и автономным: DbDataAdapter
Создание строго типизированных DataSet
Использование объекта создания команд
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий