Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Вебмастеру -> Сеппа Д. -> "Microsoft ADO.NET" -> 155

Microsoft ADO.NET - Сеппа Д.

Сеппа Д. Microsoft ADO.NET — М.: Русская Редакция, 2003. — 640 c.
ISBN 5-7502-0223-2
Скачать (прямая ссылка): mcrsftado2003.pdf
Предыдущая << 1 .. 149 150 151 152 153 154 < 155 > 156 157 158 159 160 161 .. 260 >> Следующая

adCmdText
rs.Delete rs.MoveNext
*
rs. FieldsC'Quantity") = 2 - rs.Fields("Quantity") rs.Update
350
Часть Автономная работа с данными: объект DataSet модели ADO.NET
rs.AddNew
rs. FialdsC'OrderlD") = 10503 ¦rs.FieldsC'ProductlO") = 1 ,rs.Fields( "Quantity") = 24 irs.FieldsCUnitPrice") = 18 rs.Update
rs.UpdateBatch
rs.Close en.Close
Данный код демонстрирует большинство преимуществ и недостатков передачи обновлений в БД с использованием объекта Recordset ADO, и я подробно расскажу об этом в следующих разделах этой главы.
Преимущества передачи обновлений
с использованием объектов Recordset ADO
Первое преимущество данного подхода — минимальный объем необходимого кода. Вам нужно открыть объект Recordset, изменить его содержимое и затем передать изменения в БД. Большой объем работы выполняется всего несколькими строчками кода.
Код не содержит логики обновления, поскольку ADO автоматически генерирует ее в период выполнения. Это — второе преимущество. ADO не требует от вас программно предоставить логику шмююк-ния. Фактически ее может написать человек, обладающий минимальными знаниями языка SQL: для использования функций обновления, предоставляемых ядром курсоров ADO, не требуется понимать, что такое параллелизм, блокировки, и как сгенерировать SQL-запрос UPDATE. Тот факт, что разработчикам удается создавать работающие приложения для доступа к данным, не зная основ языка SQL, — отличное подтверждение продуманности архитектуры технологии ADO. Меня постоянно поражает (в хорошем смысле), что многие разработчики передают обновления при помощи ядра курсоров ADO и совершенно не представляют, как именно ядро выполняет эту работу,
Недостатки передачи обновлений
с использованием объектов Recordset ADO
К сожалению, у функций оонопло шя. предоставляемых ядром курсоров ADO, есть и недостатки — низкая производительность и ограниченные возможности управления. С момента выхода ADO 1.5 бесчисленное множество разработчиков передавало обновления в БД средствами ядра курсоров ADO, так что эти проблемы
решаемы. Тем не менее они достаточно велики. Чтобы глубже понять указанные недостатки, посмотрим, как ядро курсоров ADO передает изменения в БД.
При вызове метода ядро курсоров ADO сканирует объект
Recordset на наличие измененных записей и преобразует изменения отдельных записей в SQL-запрос, редактирующий соответствующую запись БД. Ранее я говорил о разработчиках, создающих собственные SQL-запросы UPDATE, INSERT и
ГЛАВА 10 Передача обновлений в базу данных 351
DELETE для изменения содержимого БД. Ядро курсоров ADO гснерирусч аналогичные операторы.
Для наблюдения за SQL-обращениями к БД годится SQL Profiler. Просмотрев запросы, генерируемые ядром курсоров ADO для передачи изменений в БД, увидите вызов хранимой процедуры SQL Server с пакетом парамет-
ризованных запросов. Этот вызов эквивалентен следующим запросам:
DELETE FROM [Order Details] WHERE OrderlD = 10503 AND ProductID = 14
UPDATE [Order Details] SET Quantity = 40
WHERE OrderlD = 10503 AND ProductID = 65 AND Quantity = 20
INSERT INTO [Order Details] (OrderlD, ProductID, Quantity, UnitPrice) VALUES (10503, 1, 24, 18)
После повторного исходный запрос и изменения, программно вносимые в содержимое объекта Recordset, должны стать вам понятны, т. е. вы сможете посмотреть ь я запросы и понять их назначение, даже если не умеете создавать их самостоятельно. Преобразовывать изменения содержимого Recordset в SQL-запросы очень просто, если вам известно происхождение данных.
Нам вполне понятно происхождение данных, но как о нем узнает ядро курсоров ADO? Выбрав результаты запроса, ядро курсоров ADO также запросило из БД дополнительные метаданные. Чтобы сконструировать приводившийся выше запрос UPDATE, ядро курсоров должно знать имя базовой таблицы и столбца для каждого поля, а также обладать сведениями о первичных ключах таблиц, ^ поз'я-нутых в запросе.
Для просмотра этих данных самостоятельно достаточно воспользоваться в коде
набором Properties объекта Field ADO:
With rs. Fislds(-Quantity")
Debug.Print "BaseTableName = " & . Properties("BaseTableName") Debug.Print "BaseColuffinName = & . Properties("BaseColuinName") = &
End With
Здесь проявляется первый значительный недостаток функций обновления, предоставляемых ядром курсоров ADO, производительность. Запросы, генерируемые ядром для получения из БД сведений о таблицах, столбцах и первичных
ключах, сильно снижают производительность. созда-
ющих код для доступа к данным, известно происхождение этих данных. К сожалению, в ADO нельзя предоставить такие данные в коде и исключить необходимость получать их из БД каждый раз при открытии объекта Recordset.
Ядро курсоров ADO выполнено по технологии «черного ящика* и не позволяет программистам определять собственную логику обновления. Это второй значительный недостаток функций обновления, предоставляемых ядром курсороз ADO. И хотя логика обновления ядра курсоров ADO весьма впечатляюща, управлять ей практически невозможно. Также нельзя передавать кзгпкроизпные в объекте Recordset изменения посредством вызовов хранимых процедур. Если вам не чр.г
Предыдущая << 1 .. 149 150 151 152 153 154 < 155 > 156 157 158 159 160 161 .. 260 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100