Книги, научные публикации Pages:     | 1 |   ...   | 2 | 3 | 4 |

Предисловие Криса Селлза Development ADDISON Series WESLEY Практическое использование ADO.NET Доступ к данным в Internet Шон Вилдермьюс Практическое использование ADO.NET Pragmatic ADO.NET for ...

-- [ Страница 4 ] --

Много компаний создали свои первые Web-узлы на основе ADO и ASP, К сожале нию, слабым местом таких узлов оказались серверы баз данных, которые превышали лимит открытых соединений. Все работало хорошо, когда нагрузка не превышала сот ни посещений в сутки, но как только она увеличивалась, система становилась нерабо тоспособной. Необходимо было срочно что-то делать. Некоторые программисты пы тались решить проблему, сократив фактическое время соединения с базой данных, Компании настаивали на чтобы разработчики использовали соединения только в пределах конкретной страницы. Это помогало только до тех пор, пока не возникала необходимость в кэшировании данных. Разработчики создали множество различных решений для реализации механизма кэширования данных, но большинство из них основывались на копировании информации из базы данных в собственные структуры и их сохранении в кэше, в оперативной памяти. Опять же, все работа ло прекрасно, пока не в масштабировании кэша за пределы одного компьютера. Для того чтобы синхронизацию кэша, каждой из его частей передавался сигнал об изменении в базе данных, что, в свою очередь, приводило к обращению всех частей кэша к базе данных для обнов ления своего содержимого. С этим можно было смириться вплоть до момента возрас тания нагрузки на базу когда ее изменение приводило к целой лавине запро сов, обусловленной необходимостью одновременного обновления содержимого рас пределенного кэша. Существовали также иные решения данной проблемы: одни из них были довольно удачными, а другие Ч нет.

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

Х манипулирование информацией, хранящейся в базе данных;

Х предоставление структур данных, в которых будет храниться информация из ба зы данных за пределами ADO;

предоставление кэша в памяти, предназначенного для хранения этих структур данных.

Microsoft поняла, что такая тенденция принимает характер, и попы талась добавить поддержку отсоединенного объекта ADO Recordset. Это немного улучшило ситуацию, Разработчики знали о такой возможности, и что они умеют работать с данными в отсоединенном режиме. Поскольку на создание про екта отводилось ограниченное время, разработчики использовали подсоединенный доступ к данным с твердым намерением перейти в ближайшем будущем на отсоеди ненный доступ. Обычно этого так никогда и не происходило.

Проблемы масштабирования сервера баз данных В конце концов тактика количества соединений с базой данных ис черпывает себя, и уже не удается добиться увеличения быстродействия системы. За частую следующим шагом является попытка улучшить масштабируемость сервера баз данных. Как всегда, существует два способа масштабирования Ч "вверх" и "вширь". Масштабирование "вверх" обычно предполагает модернизацию аппарат ного обеспечения, добавление процессоров, увеличение объема оперативной памяти или добавление более быстрых жестких дисков. Эти меры эффективны лишь до оп ределенного момента.

254 ///. использование При масштабировании сервера баз данных "вширь" обычно осуществляется сег ментация (размещение баз данных на нескольких компьютерах), (создание копий данных на различных компьютерах) или организация кластеров (соединение нескольких компьютеров в один логический блок с целью разделения Для сегментации требуется поддержка информации о фактическом месте хранения данных и реализация механизма получения нужных данных из определенного места.

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

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

Создание кластеров компьютеров для сервера баз данных является еще одним популярным вариантом решения проблемы. На практике, однако же, в кластеры объединяются лишь два или четыре компьютера, что значительно ограничи вает проведение масштабирования "вширь".

Ни одно из этих решений не является оптимальным, а проведение ния "вширь" после первой итерации занимает много времени и затрагивает во систем.

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

Кэширование данных на Web-сервере Большинство Web-серверов современных публичных Web-узлов масштабируется с помощью объединения одинаковых компьютеров в кластер для обслуживания дящих запросов. Масштабирование при этом достигается за счет сокращения зависи мости от базы данных вследствие кэширования данных на Web-сервере, Информация считывается в объекты DataSet (или типизированные объекты и Глава 11. Масштабируемость и производительность приложений ADO.NET на Web-сервере. Уровень кэширования зависит от выбора приложения. В табл. 11. перечислены наиболее распространенные кэширования.

Таблица 11.1. Распространенные сценарии кэширования данных Сценарий Кэширование объекты DataSet хранятся Если пользователи находятся на формации на уровне в состоянии а поэтому в рамках то преимущества кэширования ми каждого сеанса одно обращение к данных Кэширование ин- объекты DataSet хранятся Если данные быстро меняются, то такой ме на уровне либо в состоянии либо по тод кэширования с так приложения одному объекту на процесс, а поэтому как требует частого обновления кэша. Кроме для приложения или существу- этого, должен существовать ет только одна копия данных ванный процесс, копирующий формации в объектах DataSet в данных Кэширование ин- Создается единственный объект DataSet Те же недостатки, что и у предыдущего на уровне для каждого компьютера, доступный анта сервера всем Кэширование данных на Web-сервере напоминает в ASP-мире, не счи тая упрощения компонентного проектирования за счет использования объектов DataSet и типизированных объектов DataSet. Кроме того, при использовании состоя ния сеанса становится доступен жизнеспособный и масштабируемый меха низм кэширования, основанный на сеансах. Времена, когда каждая компания была вынуждена создавать собственную систему кэширования сеансов, уже прошли.

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

Использование объектов DataSet вместо непосредственного доступа к базе данных Объект DataSet очень напоминает базу данных, хранимую в памяти. При желании можно хранить таблицы и схему данных в объекте DataSet и заставить приложения работать только с этим объектом. К сожалению, многие разработчики привыкли использовать SQL-операторы для доступа к информации, хранящейся в базе данных, так что отсутствие механизма поддержки SQL становится для них серьезным барьером.

Естественно, что от подобных привычек следует избавляться. В системе с хорошо структурированными данными необходимо изолировать Web-разработчика от SQL вне зависимости от того, что для этого будет использовано, Ч уровень или хранимые процедуры. В рамках парадигмы ADO.NET это достигается за счет использования в качестве объектной модели Web-узла объекта DataSet или типизиро ванного объекта DataSet. Помните, что сегодня информация может храниться в базе данных, а в формате XML или, что еше лучше, в своеобразном "гибриде" первого и второго. Использование класса позволяет представить хранимую в памяти базу данных в формате XML и дает разработчикам возможность применения языка XPath для создания запросов.

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

Масштабирование объектов DataSet Итак, на этапе у нас есть объект DataSet, который представляет хранимую в памяти базу и способ осуществления запросов к этому объекту.

Но как это может пригодиться при масштабировании базы данных? Дело в том, что мы можем размещать объекты DataSet на компьютерах среднего уровня. Вне зависи мости от того, как осуществляется доступ к объектам DataSet Ч через зовы или через Web-службы, Ч можно создать кластер компьютеров, который лит нам масштабировать базу данных. Это лучше, чем традиционные системы кэши рования, поскольку компьютеры с объектами DataSet могут передавать друг другу -документы, поддерживать все компьютеры в одинаковом со стоянии и избежать обращений к базе данных.

Кроме этого, в можно регулировать нагрузку на серверы среднего уровня с помощью тех же приемов, которые использовались для балансировки нагрузки на Web-серверы. Если рассмотреть удаленные вызовы то можно заметить, что соз дание экземпляров классов с помощью URL, Как и Web-приложения, нагрузку на Web-службы можно легко дозировать. Если будет принято решение об использовании удаленных вызовов, регулирование нагрузки все еще будет потому что и удаленные вызовы по протоколу HTTP, и удаленные вызовы по прото колу TCP создают объекты на основании адресов Поскольку это всего лишь ад рес нагрузку на него можно так же, как и нагрузку на приложение или Web-службу.

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

Дублирование или сегментация?

После принятия решения об использовании удаленных объектов DataSet необходимо определить стратегию хранения информации. Стоит ли создавать дубликат всей базы ных на каждом среднего уровня или следует разбить данные на сегменты?

Подробную информацию, языка запросов можно найти по а информацию о первоначальной реализации для Framework Ч по адресу:. com.

Глава 11. Масштабируемость и производительность приложений Оба решения связаны с возникновением определенных проблем. Дублирование предполагает необходимость обеспечения синхронизации копий базы данных. С дру гой стороны, сегментация требует реализации механизма поиска удаленного объекта DataSet, который содержит искомые данные. К тому же сегментация работает не очень хорошо, если нужно проводить объединение или слияние данных из различных сегментов. Теоретически можно попытаться использовать оба решения: дублировать сегменты базы данных, в объектах DataSet. В любом случае вам придется взвешивать все за и против и на основе требований конкретной предметной области выбрать оптимальное решение.

Синхронизация Если данные в объектах DataSet могут быть модифицированы или пополнены, вам придется взять на себя заботу о синхронизации различных экземпляров данных. К сча стью, в это не очень сложно. Синхронизация данных, хранящихся на не скольких различных осуществляется довольно просто. К примеру, непло хим решением является использование формата (см. главу 9) для распро странения информации об изменениях между несколькими компьютерами. Немного сложнее выглядит синхронизация компьютеров с базой данных. Для доставки сообще ний об изменении базы данных SQL Server всегда можно воспользоваться службой Microsoft Message Queue (MSMQ), однако при работе с другими базами данных анало гичная задача решается с помощью средств, специфичных для конкретной системы.

Предпочтительнее вносить изменения в базу данных на среднем уровне и рассылать остальным компьютерам сразу же после окончания ее обновления.

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

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

На На практике можно выбрать решение, основанное на использовании рассмотрен ных ранее техник. Так, данные о потребителе могут в состоянии сеанса в виде XML-кода, а объекты DataSet могут быть по компьютерам среднего уровня (образуется еше один уровень масштабирования). Один из способов проектирования системы при разработке приложения электронной коммерции показан на рис.

В этом примере получение информации о каталоге и пользователе происходит с помощью удаленных объектов DataSet. Информация о каталоге кэшируется на каж дом Web-сервере, в то время как информация о пользователях извлекается непосред ственно из удаленных объектов DataSet. Единственной частью системы, непосредст венно взаимодействующей с базой данных, является программное обеспечение на компьютерах среднего уровня. В качестве положительного побочного эффекта можно рассматривать возможность избежать непосредственных соединений между Web сервером и сервером базы данных.

это решение не подходит для всех ситуаций. Поскольку оптимальная стратегия кэширования данных определяется для каждой конкретной системы, вам придется оценить все за и против предложенного выше решения.

III. использование Компьютер Сервер Web-сервер среднего уровня баз данных Двунаправ- Обраще объект Данные ленные ние к V Г удаленные базе вызовы данных для изв Содержит лечения каталога, каталог и всю и обнов данные клиента информацию ления хранятся на о клиенте, инфор удаленном включая мации компьютере покупателя Рис. Структура масштабируемой системы, использующей Можно ли масштабировать объекты DataReader?

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

Вполне возможно, что при заполнении информацией объекта DataSet "за кулисами" используется объект DataReader. Этот единственный факт способен подсказать про граммисту правильный способ работы с объектом DataReader.

Фактически существует два случая, когда использование объекта DataReader в Web-приложении является оправданным.

Х Наличие часто данных. В этом случае объект DataReader непосредственно взаимодействует с базой данных и всегда имеет доступ к мой "свежей" Это означает, что, с одной стороны, объекты DataReader будут не очень хорошо масштабироваться, а с другой Ч при рабо те с часто изменяющимися данными использование объектов DataSet сущест венно затруднено.

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

Конечно же, использование механизма кэширования вывода ADO.NET ствует уменьшению количества связанных с масштабированием объектов DataReader. Как говорилось ранее в этой главе, механизм кэширования вывода Глава Масштабируемость и производительность приложений ADO.NET позволяет кэшировать на основе заданного критерия (строки запроса, от правляемых на обработку данных и т.п.). Например, при использовании объекта DataReader для считывания информации о конкретном товаре можно кэшировать каждую версию страницы на основе идентификационного номера товара. Более подробно кэширование вывода рассматривалось в разделе этой главы "Кэширо вание данных на Web-сервере".

Если вы все же приняли решение об использовании объектов DataReader на кон кретной странице, обязательно рассмотрите вопросы, касающиеся возможности мас штабирования. (Ведь каждый запрос этой страницы будет требовать наличия соедине ния с базой данных!) При определенных обстоятельствах это решение может оказать ся верным, но так бывает очень редко.

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

В производительность можно измерить на двух этапах: на этапе взаимо действия с базой данных (извлечение и обновление данных) и на этапе взаимодейст вия между кодом приложения и объектами DataSet.

Взаимодействие с базой данных На производительность приложения влияет лишь запросов и выбор способа обновления базы данных (см. главу "Обновление базы данных").

О настройке производительности базы данных в этой книге речь не идет, но в разделе "Несколько полезных советов" мы рассмотрим несколько важных вопросов, касаю этой темы.

Взаимодействие с объектами DataSet В большинстве случаев настройка взаимодействия с объектами DataSet позволяет сэкономить несколько секунд в рамках пятичасового марафона. Другими словами, это не стоит принимать в расчет, так как в данном случае овчинка выделки не стоит.

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

Несколько полезных советов Со временем я научился использовать ADO.NET оптимальным образом, и поэтому те несколько советов, которые я хочу дать, помогут вам, надеюсь, обойти наиболее распространенные "подводные камни" ADO.NET. В следующих разделах высказыва ются соображения по ряду вопросов, касающихся разработки приложений, ориенти 260 III. ADO.NET на взаимодействие с базой данных с помощью библиотеки ADO.NET. Воз можно, они помогут читателю сохранить хоть какую-то часть волос на его голове в процессе разработки приложения.

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

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

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

Используйте типизированные объекты DataSet для создания уровней бизнес-правил Как было показано в главе 6, типизированные объекты DataSet создаются для рекладывания на них задач обеспечения взаимодействия с базой данных и ции. Наследование типизированных классов DataSet позволяет разработать правила без необходимости создания полноценного отображения типов приложения на типы базы данных. При использовании типизированных объектов DataSet умень шается необходимость в написании нового интерфейса к данным или какого-либо кода. При изменении схемы данных типизированный класс DataSet нужно сгенерировать заново, а также модифицировать код, который от него ется. Отметим, что вы создаете меньший объем кода как на начальном этапе, так и на этапе изменения схемы. Хватит работать сверхурочно. Уйдите с работы в шесть и проведите вечер с семьей.

Сокращайте количество обращений к базе данных Обращения к базе данных стоят дорого. Повторяйте за мной: к базе данных стоят дорого". Сокращение количества к базе данных позволяет заметно увеличить производительность клиентского кода. При этом нагрузка на сер вер баз данных изменится не намного, однако клиентский код (или Web-узел) работать заметно быстрее. ADO.NET поддерживает множест венные результаты (следует отметить, что такой возможностью обладают не все управляемые поставщики), а поэтому пакетное извлечение или обновление данных может привести к увеличению производительности.

данные часто и заранее ADO.NET предоставляет тщательно продуманный механизм кэширования данных.

В Web-приложениях кэширование данных может привести к гигантскому производительности. Избегайте решений, в которых база данных является узким местом всей системы. При кэшировании всей информации, которая может быть использована повторно на среднем уровне или на Web-сервере, приложение начнет не только хорошо масштабироваться, но и быстро работать.

Глава Масштабируемость и производительность приложений Кэширование данных может оказаться очень полезным и для настольных прило жений. Обычно плата за кэширование в таких приложениях не заметна до тех пор, пока количество пользователей не достигнет гигантских размеров, однако преимуще ства от использования привязки данных Windows-форм способны перевесить любые дополнительные затраты.

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

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

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

Изолируйте разработчиков от базы данных Помимо создания уровня бизнес-логики с целью изоляции некоторых разработчи ков от базы данных следует сделать еще один шаг. Везде, где это возможно, исполь зуйте хранимые Зачем? Это лучше изолирует уровень бизнес-логики от базы данных.

За годы разработки API, скрывающих подробности реализации от конечного раз работчика, стало ясно, что подобный подход имеет множество преимуществ. К сожа лению, этот не был сделан для API доступа к базам данных. Иногда для создания сложного запроса действительно необходимо хорошо разбираться в используемой базе данных, однако чаще всего работа с базой данных сводится к вызову именованной хранимой процедуры или извлечению таблицы четко определенного формата. Под робности извлечения таблицы из базы данных не должны беспокоить конкретного разработчика. К тому же это позволяет администратору базы данных проводить с ней различные операции (настраивать, масштабировать и даже изменять структуру), не требующие внесения изменений в код приложения. Пока хранимые процедуры воз вращают необходимый результат, нет смысла разбираться в том, что и как работает "под капотом". Кроме того, хранимые предоставляют более высокую про чем динамические запросы.

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

Ограничьте использование объекта на страницах В некоторых ситуациях объект DataReader может оказаться незаменимым, но стоит быть очень осторожным Ч использование часто становится помехой для масшта бирования и повышения производительности. Если на странице ASP.NET используется 262 Часть объект то запрос этой страницы потребует создания соединения с базой данных. Механизмов кэширования в этом случае не существует. При желании определенного кэширования можно добиться с помощью компиляции запросов на сервере баз данных, но в любом случае быстродействие будет существенно снижено за счет обращений к базе данных, Используйте фабрики соединений Существует несколько причин, по которым можно порекомендовать использова ние классов фабрик соединений с базой данных.

Х Упрощение кэширования соединений. Вне зависимости от используемой методи ки кэширования соединений (каждый управляемый имеет свою ме тодику), генерирование строки соединения в одном единственном месте ляет максимизировать количество доступных соединений.

Х Изолирование Создав фабрику соединений, большинство разра ботчиков могут не беспокоиться о внешнем виде строки соединения вашей ор ганизации. На самом деле фабрика соединений должна получать строки соеди нения от внешнего кода.

Х Изолирование изменений. Так как соединения создаются в одном единственном месте, это облегчает внесение изменений в строку соединения.

Не помещайте строки соединения в исходный код Не используйте примеры из этой книги в качестве модели для хранения строк соединений. Такие примеры были созданы для обеспечения их понимания и для удобства чтения, но хранение строки соединения в коде является очень плохой Лучше всего хранить строки соединения за пределами кода. Встраивая строку соеди нения в код, программист предоставляет каждому, кто получил доступ к этой сборке, возможность получить также и доступ к базе данных. Аналогично, строки соединения в файл на Web-сервере является потенциальной брешью в Обычно информацию такого рода следует помещать в файл или в некое централизованное хранилище, которое может обслуживаться не разработ чиками (хорошим выбором может быть Active Directory).

Не предоставляйте пользователям доступ к базе данных Никогда не предоставляйте конечным пользователям доступ к базе данных ко для того, чтобы они могли работать с вашим приложением (это касается как Web-приложений, так и настольных приложений). Если у пользователей есть можность получить данные с помощью приложения, то они смогут получить доступ к данным и в обход него. По тем же причинам не позволяйте иметь прямого доступа к базе данных учетным записям SYSTEM, или пользова телю ASPNET. В каждом из этих случаев возникновение ошибки в системе безопас ности обеспечит взломщику полный доступ к базе данных. Я предпочитаю созда вать на сервере баз данных специфичные для приложения учетные записи, которые будут использоваться приложением для получения доступа к базе данных. Напри мер, для выполнения из этой книги я создал пользователя ADONET, который имеет непосредственный доступ только к базе данных Система безопасности сервера баз данных может ограничить права доступа пользо вателя ADONET до чтения данных или доступа к хранимым процедурам (что исклю чает непосредственный доступ к таблицам).

Глава Масштабируемость и приложений Резюме На этом этапе вам должно стать ясно, что ADO.NET предоставляет мощные инст рументы для разработки масштабируемых ориентированных на взаимодей ствие с базой данных. Так как конечной целью является сокращение числа обраще ний к базе данных, в качестве кэша информации можно использовать объект Объект DataSet позволяет существенно упростить создание системы кэширования, поскольку все манипуляции с базой данных, реляционно-иерархическое отображение и определение структур данных возлагается на ADO.NET. Разработчику остается лишь создать уровень бизнес-логики как часть типизированного класса DataSet. Кроме того, применение механизма кэширования вывода ASP.NET позволяет сократить ко личество к кэшу данных, Вы также узнали, что для оптимального использования ADO.NET необходимо по нять что Ч это всего лишь уровень доступа к данных. Другими слова ми, повышение эффективности взаимодействия приложения с базой данных может быть достигнуто за счет все тех же методов которые до ADO.NET. Несмотря на то что использование сильно типизированных классов позволяет повысить производительность взаимодействия приложения с ADO.NET, в общем масштабе эффект от таких изменений минимален.

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

III. Практическое использование Приложение А Стратегии перехода ADO В этом Планирование перехода на объектов ADO Когда Microsoft выпустила она забыла создать магический инструмент, осуществлять переход на платформу со старых систем. Таким образом, переносить код ADO на платформу нам придется самостоятельно.

Для того чтобы это сделать, необходимо понять фундаментальные различия между ADO и NET.

Планирование перехода на Самая сложная часть преобразования кода ADO в код ADO.NET обусловлена не различиями в синтаксисе, а фундаментальной в архитектуре этих логий. По своей природе интерфейс ADO ориентирован на работу с ными данными, a с отсоединенными. Создание моста, два края этой "пропасти", и является самой трудной частью переноса кода ADO на платформу Изменение архитектуры ADO-приложений При необходимости на платформу фрагмент следу ет приспособить для работы в отсоединенной среде. Несмотря на то что это позволит добиться улучшения его производительности и способности к менить структуру кода ADO будет не просто.

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

Преобразование кода, использующегося для создания отчетов на основе в базе данных информации Большая часть кода ADO предназначена для выполнения простых запросов и соз дания отчетов на основе результатов этих запросов. Вне зависимости от такого кода Ч используется он для выполнения простого запроса с целью списка в настольном приложении или для выполнения сложного запроса с целью отображения финансовой информации на Web-странице Ч он является простым для чтобы его можно было легко преобразовать. Ниже приведен при мер VBScript-кода, запрос к базе данных и все возвращен ные записи в элемент управления SELECT страницы ASP.

перехода ADO к ADO. NET row Измененный с обеспечения возможности кэширования содержимого объек та DataSet код все очень напоминает первоначальный код ADO. Состояние се анса используется для кэширования данных на уровне страницы. Важным аспектом является то, что при этого кода мы также делаем шаг в сторону отсоединенного доступа к данным.

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

Dim conn, rs Создание строки соединения const DBDSN & & б & 268 А Элементы перечислений ADO.

const const const adLockBatchOptimistic = ' Создание объекта соединения.

set conn Получение результатов set rs "CUSTOMER", conn, adOpenKeyset, adLockBatchOptimistic Изменение информации в базе if <> true then Редактирование текущей = "12345" Добавление новой записи.

"Bob" = "Smith" ' Обновление базы end if ADO.NET не поддерживает подобное обновление данных, но его можно довольно точно скопировать путем использования объекта DataSet в отсоединенном режиме доступа.

// Создание строки соединения.

const DBDSN + + + +.

// Создание объекта OleDbConnection conn - new = DBDSN;

// Создание объекта команды.

new = conn;

"SELECT * FROM // Создание объекта DataAdapter.

OleDbDataAdapter dataAdapter new // DataSet = new Стратегии перехода от ADO к // Определение переменной для упрощения доступа к DataTable custTbl // Изменение первой строки таблицы.

= // Добавление в таблицу новой DataRow newRow = = "Bob";

= "Smith";

custTbl. Rows (newRow) // объекта // для обновления = new // В итоге мы получаем идентичную функциональность, реализованную в отсоеди ненном режиме доступа к данным. Следует особо отметить, что в приведенном выше коде нет оператора открытия соединения. Задача объекта DataAdapter заключается в поддержке соединений как можно более короткой длительности;

следовательно, он автоматически открывает соединение при загрузке данных и закрывает его сразу же после ее завершения. Аналогичные действия предпринимаются при вызове метода Update. Кроме того, для создания команд обновления и вставки данных используется объект Этот объект предоставляет идентичную той, что скрыта "за кулисами" в ADO, а именно: создание команд SQL с целью со базе данных о требуемых изменениях.

Чего не хватает в ADO.NET?

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

Х Редактирование "на месте". Все манипуляции с базой данных в ADO.NET со вершаются в отсоединенном режиме доступа. Обновление и добавление запи сей в соответствии с принципом не имеет эквивалента в ADO.NET.

Х Блокировка баз данных. В ADO.NET нет способа блокировки базы Изъятие блокировок из ADO.NET было обусловлено их очень высокой ценой и неспособностью к масштабированию. Другими словами, при редактировании строки ее нельзя заблокировать. В такой ситуации необходимо либо создать код для обеспечения параллелизма в отсоединенном режиме доступа к данным (см.

главу 8, "Обновление базы данных"), либо использовать объект CommandBuilder для обеспечения оптимистического параллелизма при обновлении базы 270 Приложение А объектов ADO При анализе кода ADO с целью его преобразования в код может воз никнуть соблазн отобразить код ADO на код ADO.NET построчно. Хотя это и не всегда возможно (как было показано в предыдущем разделе), существуют некоторые специфичные позволяющие преобразовать типы данных и объекты ADO в типы данных и объекты ADO.NET.

Отображение типов данных ADO на типы данных Не каждый тип данных ADO имеет прямой эквивалент в При работе с дан ными ADO в среде (используя взаимодействие с СОМ или собственные компо ненты, данные непосредственно из ADO) необходимо знать отображе ние типов данных ADO на типы данных Framework. Тип объекта ADO Recordset определяется динамически, что напоминает определение типов объектов и Для того чтобы отобразить фактический тип объекта ADO на соответст вующий тип Framework, необходимо знать отображение типов ADO на типы ADO.NET. Это отображение показано в табл.

Таблица А.2. Отображение между типами ADO и типами Тип ADO Тип Framework Тип ADO Тип Framework (Da t а (Da ta Null DateTime DateTime Guid Int32 adError Obj ect adIDispatch Object Приводится к Intl adVariant Object Приводится к Int Приводится к adBinary Приводится к Decimal adSingle Single adChar String Double String Decimal adBSTR String Decimal He Decimal He adDate He поддерживается adDBDate Эта таблица взята непосредственно с Web-узла MSDN. Ее можно найти по Стратегии ADO к ADO.NET Поставщики и управляемые поставщики При преобразовании кода ADO в код для доступа к базе данных можно использовать управляемый поставщик OLE DB. Управляемый OLE DB поддерживает те же строки соединения и поставщики OLE которые использова лись раньше, с одним исключением Ч управляемый поставщик OLE DB специально не поддерживает поставщик ODBC. Для того чтобы использовать поставщик ODBC, вам придется воспользоваться управляемым поставщиком ODBC, который не постав ляется в составе Visual Studio или Framework. Управляемый поставщик ODBC можно загрузить с Web-узла Microsoft по адресу:

При работе с управляемым ODBC можно использовать те же строки со единения, за исключением атрибута Provider. Так, код должен преобразован следующим образом:

Преобразование установки соединения ADO поддерживает целый набор различных типов и режимов соединений, которые предоставляют достаточно широкий объем функциональности на стороне сервера. Так как библиотека ориентирована на отсоединенный режим доступа к дан ным, в ней отсутствует поддержка курсоров, что существенно упрощает создание со единений. Ниже приведен код ADO, предназначенный для открытия соединения в режиме чтения/записи данных.

Создание строки соединения.

const & S & ' Элемент перечисления ADO.

const = Установка set conn = adModeReadWrite DBDSN Прямое преобразование такого кода провести невозможно, поскольку в отсутствует понятие соединения, предназначенного для чтения/записи данных. Ниже приведен код ADO.NET, примерно соответствующий коду ADO.

// Создание соединения.

const string DBDSN = + + + + // Установка соединения.

OleDbConnection conn new = DBDSN;

272 Приложение А ADO и отличаются способом закрытия соединений при отсутствии их явного закрытия. Если бы соединения всегда явно, все было бы отлично.

Как в ADO, так и в ADO.NET соединение закрывается (если оно не было закрыто ра нее) при уничтожении Интерфейс ADO основан на технологии СОМ, а по этому для уничтожении объектов используется счетчик ссылок. В используется механизм сбора мусора. Именно в этом и заключается проблема: при освобождении соединения ADO объект будет уничтожен, если счетчик ссылок равен нулю, что, в свою очередь, приведет к закрытию соединения. В ADO.NET все работает мусора проводит уничтожение объектов только при нехватке памяти, а поэтому нельзя точно сказать, когда будет уничтожен объект после его из области видимости. На самом деле, в долго объект может быть уничтожен даже через несколько дней. С целью смягчения данной проблемы в предоставляется интерфейс Disposable, поддерживающий единственный метод Dispose (). Интерфейс IDisposable позволяет уничтожать объекты детер минированным образом. Я хочу дать вам два совета, касающихся преобразования кода установки соединения ADO. Во-первых, всегда явно вызывайте метод close О при завершении работы с соединением. Во-вторых, те также и метод Dispose Вот так должен выглядеть код использования объекта соединения:

// Создание строки соединения.

const string = + + + + // Создание объекта conn new = DBDSN;

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

Приведенный ниже код ADO:

' Создание объекта set = conn "SELECT LastName FROM CUSTOMER" будет преобразован в следующий код ADO.NET:

// Создание объекта команды.

cmd new = conn;

"SELECT LastName FROM Стратегии перехода от ADO к ADO. NET Преобразование кода создания объекта Recordset Объект ADO Recordset не имеет единственного эквивалента в ADO.NET. На самом деле он имеет два эквивалента. Так, объект DataReader очень напоминает однона правленный объект Recordset. В большинстве случаев можно осуществить преобразо вание по типу "один к одному", в результате чего приведенный ниже код ADO:

' Получение результатов set rs трансформируется в код ADO.NET:

// Получение результатов запроса.

QleDbDataReader Особенность этого подхода заключается в том, что объект DataReader представляет собой однонаправленный позволяющий перемешаться только вперед и не предусматривающий редактирования данных.

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

' строки соединения.

const DBD3N & & & ' Получение результатов выполнения set rs = DBDSN будет преобразован в следующий код ADO.NET:

// Создание строки соединения.

const string DBDSN = + + + + // Создание объекта соединения.

OleDbConnection conn new DBDSN;

// Создание объекта команды.

cmd = new = conn;

"SELECT * FROM // Получение результатов выполнения OleDbDataReader rdr = Вторым эквивалентом объекта Recordset является объект ADO.NET Объекты DataTable Ч таблицы данных, которые всегда содержатся в объекте Ниже приведен код ADO.NET, в котором используется объект DataTable.

// Создание строки const string DBDSN = 274 А + + // Создание объекта соединения.

conn new = // Создание объекта команды.

cmd new {) conn;

= "SELECT * FROM // Создание объекта DataAdapter.

OleDbDataAdapter dataAdapter new // Создание DataSet (который будет содержать объект DataSet dataSet = new // Получение результатов выполнения запроса.

// Определение переменной для упрощения доступа к таблице.

DataTable = Использование объектов ADO Recordset в ADO.NET Распространенной стратегией в ADO являлось работающих с отсоединенным или подсоединенным объектом Recordset. Объекты Recordset ис пользовались в качестве контейнеров данных, которые могли даже ду различными уровнями в распределенном окружении. Так как не все могут лить себе роскошь преобразования целой системы, вы можете воспользоваться спо собностью ADO.NET принимать в качестве входного параметра объект Recordset. Для того чтобы это сделать, необходимо добавить ссылки на ADO и на компонент, вращающий объект Recordset. Microsoft включила в Visual Studio стандартную сборку взаимодействия с ADODB, поэтому необходимо лишь добавить ссылку на сборку adodb. После этого вы можете использовать объект Recordset в качестве пара метра при заполнении объекта DataSet, как показано ниже:

// Получение объекта Recordset.

rs Создание объекта DataAdapter без указания // команды или соединения, так как эта информация // хранится в объекте Recordset.

OleDbDataAdapter dataAdapter = new DataSet dataSet new // Заполнение таблицы объекта помощью объекта RecordSet.

rs, Это приведет к заполнению объекта DataSet, но обратного пути нет, т.е. не ствует встроенной поддержки обновления объекта Recordset на основе объекта Set или DataTable.

Стратегии от ADO к Резюме Если изменить свою собственную точку зрения на механизмы взаимодействия с базами данных, можно легко преобразовать код ADO в код ADO.NET. Библиотека изначально проектировалось с целью устранения некоторых присущих ADO проблем, касающихся разработки и систем с высокой нагруз кой. Тем не менее "слепое" преобразование кода ADO в код ADO.NET не позволит избавиться от накопленных ранее проблем, связанных с и мас штабированием. Переход к ADO.NET требует нового взгляда на рабо ту в отсоединенном режиме доступа к данным.

276 Приложение А Предметный указатель О Active Server Pages (ASP), 253 OLE for Databases (OLE DB), ActiveX Data Objects (ADO), Open Database Connectivity (ODBC), ActiveX Data Objects for ADO.NET Structured Query Language (SQL), краткая история универсального доступа к данным, объектная модель управляемого Т данных, Tabular Data Stream (TDS), преимущества использования, пространства имен, структуры данных, X American National Standards Institute XML Schema Definition (XSD), (ANSI), Application Programming Interface (API), Д Делегат COM+, Component Object Model Create, Read, Update, Delete И D Интеграция с XML XML, Data Access Objects (DAO), заполнение объекта DataSet данными из Data Source Name (DSN), XML-файла, класс DataSet и XML, G класс XmlDataDocument, поиск данных в объекте DataSet с Globally Unique Identifier помощью запросов преобразование данных объекта H в формат XML, преобразование объекта DataSet с Hypertext Transfer Protocol (HTTP), языка XSLT, пространства имен объекта DataSet, сохранение данных объекта DataSet в Internet Information Server (IIS), 19 формате стратегии использования XML документа в формате M схема объекта DataSet, Microsoft Developer Network (MSDN), Интерфейс Microsoft Message Queue (MSMQ), IDataReader, IDbCommand, IDbConnection, Предметный указатель DataTable.Select(), Исключения К Команда, выполнение, использование параметров, пакетные запросы, запросы, GetChildRows(), создание, создание оболочки для хранимой типы, транзакция, Кэширование данных на стороне клиента, на стороне сервера, несколько полезных советов, IsDBNull(), Метод Метод Read(), ChangeDatabase(), Save(), Table 26;

179;

DataBind(), * О Обработка ошибок в Объект DataAdapter DataRow.IsNull(), вывод схемы объекта DataSet, использование свойства множественные объекты DataTable, обновление объекта DataSet, описание, DataSet.ReadXml(), создание объекта DataSet на основе информации, базе данных, 157 Объект DataReader 278 Предметный указатель доступ к данным, создание создание программным путем, обработка создание схемы программным путем, результирующих наборов данных, ПО описание, сортировка данных с помощью объекта привязка данных, 248 DataView, работа с метаданными, 86 состояние строки, создание, сохранение данных объекта DataSet в функциональность, 80 формате чтение данных, 76 структура, Объект DataSet схема столбца, версии строк, типизированный объект DataSet вывод схемы с объекта создание, DataAdapter, 107 использование, добавление строк, настройка сгенерированного кода с заполнение данными, специальных изменение данных, 156 использование автоинкрементных упрощение уровня использование вычисляемых столбцов, триггеры, удаление строк, использование свойства TableMappings, фильтрация с помощью объекта DataView, использование языка XSD для чтение и запись значений столбцов определения схемы, 109 строки, множественные объекты DataTable, описание, п определение схемы, Пакетные запросы, первичные ключи, Параллелизм, вдоль отношений, деструктивный параллелизм, поиск данных с помощью запросов обработка нарушений параллелизма.

XPath, поиск с помощью метода оптимистический параллелизм, 179;

DataTable. Select, пессимистический параллелизм, 179;

поиск с помощью объекта View, Переход к преобразование данных объекта DataSet объектов в формат преобразование с помощью языка изменение архитектуры ADO XSLT, приложений, пространства имен объекта DataSet, использование объектов ADO Recordset реализация деструктивного в ADO.NET, параллелизма, отображение типов данных ADO на реализация оптимистического типы данных параллелизма, поставщики и управляемые реализация пессимистического поставщики, параллелизма, преобразование кода создания объекта слияние, Recordset, создание на основе преобразование кода создания объекта команды, создание на основе информации, преобразование кода установки хранящейся в базе данных, соединения, создание ограничений, Предметный указатель Перечисление Rows, SelectCommand, CommandType, Table Mappings, 172 Update Событие Isolation 217 108 Changing, 60 SqIDbType, XmlReadMode, 219 Disposed, данных, ASP.NET, 246 привязка к элементу управления 240 RowDeleted, привязка с объекта DataReader, 248 RowUpdating, привязка типа "родитель-потомок", 242 простая привязка, 237;

246 Соединение, сложная привязка, 239;

247 встроенная система безопасности, Пространство имен изменение базы данных, 23;

97 пула соединений, 30;

98 управляемый поставщик данных System.Data.Odbc, 30;

98 ODBC, 30;

98 управляемый поставщик данных OLE 30;

98 DB, System.Data.SqlClient, 30;

98 управляемый поставщик данных Oracle, управляемый поставщик данных SQL Server, Свойство продолжительность ожидания установки соединения, Error, события объекта Connection, DataBindings, строка соединения, DataColumn. Expression, управляемый поставщик ODBC, управляемый поставщик OLE DB, управляемый поставщик Oracle, управляемый SQL Server, DataValueField, фабрика соединений, View. Sort, Delete 118 Транзакция, MissingSchemaAction, 107 службы Enterprise Services и СОМ+, Position, 245 точки сохранения в транзакциях SQL 27 Server, 194 уровни изоляции, 280 Предметный указатель Шон Практическое использование Доступ к данным в Internet Литературный редактор С. Г.

Верстка Удалое Художественный редактор С. А.

Корректоры А. О. В.

Издательский дом "Вильяме".

101509, Москва, ул. Лесная, д. 43, стр. 1.

Изд. лиц. ЛР № 090230 от 23.06. Госкомитета РФ по печати.

Подписано в печать 22.04.2003. Формат 70x100/16.

Гарнитура Times. Печать офсетная.

Усл. печ. л. 23,22. л. 14,95.

Тираж 3000 экз. Заказ № 2851.

Отпечатано с диапозитивов в ФГУП "Печатный двор" Министерства РФ по делам печати, и средств массовых коммуникаций, 197110, Санкт-Петербург, 15.

основы ADO.NET Разработанная компанией Micro soft технология доступа к данным ADO.NET позволяет Windows-при ложениям осуществлять взаимо Боб действие с базами данных множе ства различных производителей, что является одним из основных требований при создании Internet приложений и построении распре деленных вычислительных сред.

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

Боб Бошемин Кроме этого, на примерах различ ных типов структур данных проде монстрировано использование ADO.NET при решении всевоз можных задач, с обеспе чением доступа к данным. Особое внимание уделено первичным це лям проектирования ADO.NET достижению баланса между уни версальностью и эффективностью, обеспечению масшта бирования, параллельной обработ ке данных и устойчивости. Про граммисты, использующие такие API доступа к данным, как OLE DB, ADO, ODBC и JDBC, могут www.wiliiam5publishing.com обращаться к этой книге как к спра вочнику, содержащему информа цию о соответствии классов и функ ций вышеназванных API классам и методам ADO.NET.

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

СОЗДАНИЕ ПРИЛОЖЕНИЙ ASP.NET, XML И ADO.NET В СРЕДЕ VISUAL BASIC.NET Данная книга представляет собой руководство для разработчиков, которое содержит подробное опи сание средств языка Visual Basic Джеффри П.

опирающихся на Крис ти классов общей среды выполне ния Ч Common Language Runtime) и инфраструктуры В ней значительное внимание уделено вопросам перехода на но вую инфраструктуру поддержки Джеффри П. Мак-Манус и Крис Кинсмен приложений и приведены исчер пывающие рекомендации по под Создание готовке существующего кода ASP для работы на платформе приложений ASP.NET, ASP.NET. В книге подробно описа и ADO.NET ны классы инфраструктуры стра среде Visual Basic ницы в среде ASP.NET, включая сам объект Page, дочерние классы и элементы управления пользовательским интерфейсом (элементы управления HTML и серверные элементы управле ния). Рассматриваются методы проектирования пользовательско го интерфейса для устройств с малыми форм-факторами, как мобильные телефоны и карманные компьютеры. Книга предназначена для программистов www.wilHamspublishing.com и среднего уровня, стремящихся освоить новые средства языка Visual Basic в продаже Мир книг по компьютерным наукам от издательской группы DISCRETE Искусство я кнут ISBN 5-8459-0122- 5-8459-0179-0 5-8459-0109-Х I S6N ISBN ISBN 5-8459-0192- программного обеспечения ISBN 5-8459-0330- КАЯ * www.dialektika.com www.williamspubli5hing.com Мир книг по технологиям программирования от издательской группы "ДИАЛЕКТИКА СИСТЕМЫ БАЗ ДАННЫХ полный ISBN 5-8459-0080-8 5-8459-0189-8 ISBN 5-8459-0261-4 ISBN 5-8459-0384-Х ОСНОВНЫЕ ПРОГРАММИРОВАНИЯ ISBN 5-8459-0360-2 ISBN 5-8459-0210-Х ISBN 5-8459-0192- METHODS ISBN 5-8459-0388-2 ISBN ISBN ISBN 5-8459-0437- www.dialektika.com Мир книг по базам данных от издательской группы ISBN 5-8459-0109-Х ISBN 5-8459-0355-6 ISBN 5-8459-0158-8 ISBN 5-8459-0291- 5-8459-0302-5 ISBN ISBN fcl www.dialektika.com www.williamspublishing.com Мир книг по UML от издательской группы "ДИАЛЕКТИКА С 5-8459-0276-2 ISBN 5-8459-0250- SBN 5-8459-0239-8 ISBN ISBN 5-8459-0265-7 ISBN ISBN 5-8459-0346-7 ISBN ПРИМЕНЕНИЕ ШАБЛОНОВ С ISBN 5-8459-0393-9 ISBN 5-8459-0299-1 ISBN 5-8459-0425-0 ISBN 5-8459-0355- www.dialektika.com www.ciscopress.ru Мир книг по разработке программного обеспечения от издательской группы тестирование программного обеспечения ISBN ISBN 5-8459-0394-7 ISBN ISBN 5-8459-0367-Х И ISBN ISBN ISBN 5-8459-0336-X ISBN 5-8459-0329- ISBN 5-8459-0413-7 5-8459-0233-9 ISBN 5-8459-0270-3 ISBN 5-8459-0448-X www.dialektika.com iamspublishing.com ru Framework "Это моя любимая книга по Ее автор, безусловно, обладает уникальными знаниями в области разработки приложений баз данных и прекрасно владеет материалом. Данная книга представляет интерес для опытных разработчиков, так и для тех, кто делает первые шаги в освоении платформы Microsoft Ч старший инженер по разработке программного обеспечения, New Dawn Technologies (ранее инженер по поддержке процесса разработки, Microsoft Corporation) Эта книга является практическим руководством по использованию первой библиотеки доступа к данным, спроектированной специально для упрощения создания Web приложений. Содержащийся в книге материал поможет разработчикам изучить основные концепции и познакомиться с практическими методами решения распространенных задач.

На первых страницах книги автор предлагает совершить небольшой экскурс в историю создания компанией Microsoft технологий универсального доступа к данным и проследить эволюционный путь Большая часть книги посвящена использованию библиотеки для взаимодействия Книги серии Microsoft с базами данных и остальной частью Framework. Кроме того, Development написаны автор дает ряд полезных советов по созданию масштабируемых и высокопроизводительных приложений. Книга включает в себя и одобрены ведущими множество примеров исходного кода на языке С#, а также имеет специалистами и разработ Web-узел поддержки по адресу: www.adoguy.com/book, чиками технологий Microsoft на котором, помимо примеров на языке Visual Basic можно включая команду найти различные средства, упрощающие создание создателей платформы приложений. В конце книги автор подробно излагает стратегию Microsoft и специалистов преобразования кода ADO в код ADO.NET.

компании В книге рассмотрены следующие темы:

Освещая вопросы проектиро Х Работа с данными в отсоединенном режиме вания, структуры и реализации Х Подключение к базе данных с использованием средств Microsoft эти книги пред ADO.NET назначены для разработчиков Х Использование объектов Command и DataReader и студентов, поддержавших Х Создание объекта DataSet.NET-революцию.

Х Создание и использование типизированных классов DataSet Х Манипулирование данными, содержащимися в объекте DataSet Х Обновление базы данных на основании информации, содержащейся в объекте DataSet www.williamspublishing.com Х Интеграция ADO.NET и XML Х Привязка данных к элементам графического интерфейса Х Повышение масштабируемости и производительности ADO.NET-приложений А Лаконичное изложение материала в сочетании с полезными ADDISON советами и подробными примерами делает данную книгу WESLEY бесценным источником знаний для всех разработчиков, желающих приобрести навыки практического использования ADO.NET.

ISBN 5-8459-0450- Шон Ч основатель Web-узла ADOGuy.com и разработчик приложений баз данных более чем с 16-летним стажем. Шон создал множество приложений баз данных для компаний, занимающихся бухгалтерским учетом, торговлей недвижимостью, предоставлением медицинских услуг, а также различных услуг через Internet. Его статьи печатаются во многих журналах, среди которых Magazine и Windows Magazine.

Pages:     | 1 |   ...   | 2 | 3 | 4 |    Книги, научные публикации