Создание приложений ASP.NET, XML и ADO.NET в среде Microsoft Visual Basic.NET

• Недостатки технологии ASP
• Введение в ASP.NET

Сразу после внедрения технологии ASP (Active Server Pages - активные серверные страницы), которое произошло примерно пять лет тому назад, казалось, что эта технология способна заменить все существовавшие в то время сложные и неудобные методы создания динамического информационного наполнения в Web. В тот период для создания динамического информационного наполнения Web в основном применялись сценарии CGI (Common Gateway Interface - общий шлюзовой интерфейс) или нестандартные серверные сменные модули. После выпуска корпорацией Microsoft версии ASP 1.0 ситуация коренным образом изменилась. Платформа ASP 1.0 предоставляла гибкую, надежную архитектуру создания сценариев, которая позволяла разработчикам быстро создавать динамические приложения Web. Разработчики получили возможность писать свои сценарии на языках VBScript или JScript, а корпорация Microsoft предоставила множество служб, позволяющих упростить разработку. В тот момент казалось, что потребности разработчиков полностью удовлетворены. Однако по мере дальнейшего развития Web стали очевидны многие недостатки этой платформы, которые не преодолены до настоящего времени.

Разделение кода и средств презентации

По мере роста популярности Web в начале 90-х годов последовательно происходила смена основных подходов к созданию информационного наполнения. На первом этапе разработчики Web формировали статические документы HTML и связывали их ссылками между собой. В это время главным образом создавались Web-узлы с постоянным информационным наполнением, поэтому основное внимание уделялось их внешнему оформлению. На втором этапе стали широко применяться методы динамического создания информационного наполнения. Разработчики приступили к созданию регистрационных форм и небольших функциональных модулей, а также размещению их на существующих Web-узлах. На третьем этапе были объединены достижения первого и второго этапов. Web-узлы с самого начала разрабатывались для использования в интерактивном режиме; они в большей степени стали напоминать приложения и в меньшей - периодические выпуски журналов с вложенной квитанцией на подписку. В большинстве случаев проекты интерактивных страниц этих Web-узлов разрабатывались примерно по такому принципу:

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

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

С выпуском комплекта инструментальных средств Visual Studio 6 в сентябре 1998 года стало очевидно, что корпорация Microsoft осознала важность этой растущей проблемы и пытается справиться с ней с помощью нового средства языка Visual Basic 6 - классов Web. В классах Web была предпринята попытка отделить средства презентации страницы от взаимодействующего с ними кода. В этой технологии разработки подобное разделение достигается путем использования шаблона HTML и предоставления возможности выполнять замену дескрипторов в этом шаблоне. Однако с введением классов Web появился целый ряд новых проблем. Хотя сама идея была превосходной, ее реализация имела определенные недостатки. Во-первых, классы Web были реализованы полностью на языке Visual Basic, а это требовало от профессиональных разработчиков ASP изменить свой подход к созданию приложений. Во-вторых, корпорация Microsoft не смогла решить проблемы масштабируемости, связанные с недостатками моделей многопотоковой обработки ASP и Visual Basic. По двум указанным выше важным причинам, а также в связи со многими другими не рассматриваемыми здесь обстоятельствами классы Web так и не получили широкой поддержки разработчиков.

Применение языка сценариев в качестве основы

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

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

Управление состоянием

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

Введение в ASP.NET

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

Архитектура платформы

Платформа ASP, которая далее в этой книге часто именуется ASP.old, была основана на использовании фильтра ISAPI (Internet Server Application Programming Interface - интерфейс прикладного программирования для сервера Internet), который был специально предназначен для взаимодействия с сервером IIS (Internet Information Server - информационный сервер Internet). Это приложение было монолитным по конструкции и очень мало опиралось на внешние службы.

Примечание

В тот период времени, когда в основном применялась версия сервера IIS 5.0, на платформе ASP в качестве внешней службы использовался сервер транзакций Microsoft (MTS - Microsoft Transaction Server).

Платформа ASP.NET все еще остается фильтром ISAPI. Однако, в отличие от ASP.old, платформа ASP.NET опирается на большое число "внешних" служб, принадлежащих к инфраструктуре .NET. Но платформа ASP.NET и инфраструктура .NET настолько тесно связаны, что инфраструктуру .NET даже сложно назвать внешней службой. Тем не менее, поскольку доступ к ней предоставляется и для приложений, выходящих за пределы платформы ASP.NET, ее следует рассматривать как внешнюю службу. В конечном итоге такой подход предоставил огромные преимущества для разработчика ASP.NET. Он больше не должен создавать все с нуля, поскольку инфраструктура .NET предоставляет большую библиотеку заранее подготовленных функциональных средств.

Дистрибутив инфраструктуры .NET состоит из трех основных частей: общая среда выполнения, базовые классы инфраструктуры .NET и платформа ASP.NET.

Общая среда выполнения

Общая среда выполнения (CLR - Common Language Runtime) представляет собой машину выполнения для приложений инфраструктуры .NET. Хотя многие считают ее интерпретатором, в действительности это не так. Приложения .NET являются полностью откомпилированными исполняемыми модулями, в которых среда CLR применяется для получения доступа к множеству служб во время выполнения. Некоторые из этих служб перечислены ниже:

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

CLR - это среда выполнения, которая позволяет отделить функциональные средства от операционной системы. Поэтому код, предназначенный для выполнения в среде CLR, является в определенном смысле "независимым от платформы", при условии, что для платформы назначения предусмотрена реализация CLR.

Управляемое выполнение

Среда CLR - это не просто библиотека или хранилище функций, к которым обращается программа в ходе выполнения. Эта среда взаимодействует с выполняемым кодом на многих уровнях. Например, загрузчик, предусмотренный в CLR, осуществляет проверку допустимости кода, определяет права доступа и выполняет ряд других задач во время загрузки каждого фрагмента кода. Среда CLR управляет также распределением памяти и предоставляет доступ к ресурсам. Термин "управляемое выполнение" наглядно описывает взаимодействие среды CLR и выполняемого кода для создания надежных приложений.

Функциональная совместимость языков

Одним из самых значительных недостатков современных методов разработки, основанных на использовании модели компонентных объектов (COM - Component Object Model) или API-интерфейсов, является то, что применяемые при этом интерфейсы обычно предназначены для работы только с определенным языком. При разработке компонента, который должен применяться в программе на языке Visual Basic, разработчик обычно создает интерфейсы немного иначе, чем при разработке компонента, предназначенного для программы на языке C++. Это означает, что если перед разработчиком поставлена задача подготовить компоненты, предназначенные для использования в обоих этих языках, он должен при создании интерфейса выбрать подход, предусматривающий применение только минимального набора средств, подходящего для обоих языков, или создать отдельный интерфейс для каждого языка. Безусловно, что такой подход к разработке компонентов нельзя назвать слишком продуктивным. Со второй проблемой многие разработчики настолько свыклись, что просто ее не замечают. Она состоит в том, что большинство компонентов приходится разрабатывать только на одном языке. Например, если на языке C++ создан компонент, предоставляющий доступ к объекту Employee (Служащий), то в дальнейшем нельзя сформировать на его основе объект Developer (Разработчик) в программе на языке Visual Basic. Это означает, что в большинстве проектов разработки для обеспечения повторного использования обычно приходится выбирать только один язык.

С появлением платформы .NET ситуация изменилась коренным образом. Функциональная совместимость языков была предусмотрена в ней с самого начала. Но для этого все языки .NET должны соответствовать общей языковой спецификации (CLS - Common Language Specification), регламентирующей базовый уровень функциональных средств, который должен быть реализован в каждом языке для обеспечения его взаимодействия с другими языками. Спецификация CLS написана таким образом, что каждый язык может сохранить свои уникальные особенности, но вместе с тем успешно взаимодействовать с другими языками, принадлежащими к среде CLR. Спецификация CLS включает также ряд типов данных, которые должны поддерживаться всеми языками, соответствующими этой спецификации. Указанное ограничение позволяет устранить общую проблему для всех разработчиков: создание интерфейса, в котором применяются типы данных, не поддерживаемые другим языком. Спецификация CLS поддерживает также наследование объектов как на уровне исполняемого кода, так и на уровне исходного кода, что дает возможность разработчику создать упомянутый выше объект Employee на языке C#, а затем реализовать на его основе производный объект в программе на языке Visual Basic.

Для разработчика все это означает, что повторное использование кода становится намного проще. При условии, что код подготовлен для платформы .NET, не имеет значения, на каком языке он написан. По сути, выбор языка в большей степени становится делом вкуса, а не диктуется необходимостью. Все языки в инфраструктуре .NET теоретически эквивалентны друг другу, поэтому нельзя достичь повышения производительности или расширения функциональных возможностей, например, используя язык C# вместо VB. Разработчик вправе выбирать язык, на котором ему легче работать.

Новые средства платформы ASP.NET

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

Интерфейс Web Forms

Разрабатывая интерфейс Web Forms, корпорация Microsoft пыталась решить проблему разделения кода и дизайна. Теперь платформа ASP.NET позволяет воспользоваться моделью вспомогательного кода, которая напоминает средства программного компонента Forms Designer (Проектировщик форм) языка Visual Basic. Это означает, что на современном этапе разработчик может разместить весь код в отдельном файле, но при этом обеспечить взаимодействие кода со страницей. Такое разделение осуществляется путем предоставления новой управляемой событиями модели, которая применяется в процессе выполнения кода страницы, а также предоставления объектной модели, которая базируется на коде HTML, входящем в состав страницы. Вместо применения модели последовательного линейного выполнения кода страницы от начала до конца используется модель, в которой в процессе выполнения кода страницы активизируются события. Код перехватывает эти события и отвечает на них, взаимодействуя с объектной моделью, основанной на коде HTML. Это позволяет успешно решить проблему, которая связана с тем, что проектировщики, дорабатывая код HTML, нарушают работу программного кода.

В дополнение к новой модели выполнения, корпорацией Microsoft была также создана новая модель серверных элементов управления. В отличие от печально известных элементов управления этапа проектирования (Design Time Control), применявшихся в инфраструктуре Visual Interdev, эти новые модели представляют собой невероятно удобные реализации самых распространенных объектов, предназначенных для создания графического интерфейса. Такие модели не опираются на какие-либо средства, зависящие от конкретной версии броузера, и применяются на сервере, а не на клиенте. В тех случаях, если с помощью этих моделей должен быть создан код, зависящий от версии броузера, они позволяют определить применяемую версию и выбрать подходящий для нее набор функциональных средств. Дополнительная информация об интерфейсе Web Forms приведена в главе 3, "Инфраструктура страницы".

Службы Web

Ушло в прошлое первое и второе поколения приложений Web и стало очевидно, что теперь можно расширить возможности Web и решить проблемы, появившиеся еще до создания этой технологии обмена информацией. В свое время предприятия обменивались данными с использованием средств EDI (Electronic Data Interchange - электронный обмен данными) по специализированным сетям (VAN - Value Added Network). Эти средства обмена данными функционировали достаточно успешно, но стоимость получения доступа к специализированной сети была высока, а сложность реализации различных протоколов EDI, стандартизированных для конкретных отраслей производства, была весьма велика, поэтому в обмене информацией могли участвовать только самые крупные компании.

Службы Web предоставляют способ передачи производственную информацию по Internet (а не по дорогостоящим специализированным сетям) с помощью таких промышленных стандартных протоколов, как HTTP, XML и TCP/IP. Теперь службы Web могут быть реализованы на платформе .NET настолько легко, что в обмене производственной и коммерческой информацией могут принять участие не только предприятия любого размера, но и частные лица. Службы Web не только заменили традиционные протоколы EDI, но и открыли много возможностей, которые не были осуществимы с помощью средств EDI. Дополнительная информация об этом приведена в главе 7, "Web-службы".

Доступ к данным

Ко времени создания первой версии ASP 1.0 корпорация Microsoft занималась интенсивной разработкой средств доступа к данным. В этот период разработчики на языке Visual Basic предпочитали использовать технологию RDO (Remote Data Object - удаленный объект данных). С началом поставки версии Visual Basic 5.0 в феврале 1997 года была впервые представлена технология ADO (ActiveX Data Objects - объекты данных ActiveX). Она была предназначена для использования в качестве новой модели доступа к данным всех типов и совмещена еще с одной новой технологией - OLE DB (OLE для баз данных).

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

ADO.NET представляет собой новую технологию доступа к данным, в которой учтены все уроки, полученные корпорацией Microsoft на опыте разработки и эксплуатации ADO, RDO, OLE DB, ODBC и других предшествующих реализаций средств доступа к данным. Технология доступа к данным ADO.NET с самого начала была спроектирована с учетом очень тесного взаимодействия с языком XML и эффективной работы с автономными источниками данных. Дополнительная информация по этой теме приведена в главе 12, "Создание приложений базы данных в среде ADO.NET".

Развертывание приложений

Одним из постоянных источников разногласий между разработчиками ASP всегда был вопрос о том, какой относительный объем кода должен быть перенесен в COM-объекты. Некоторые авторы утверждали, что весь код должен находиться в COM-объектах, а код ASP должен содержать единственный вызов метода, предназначенный для запуска COM-объекта на выполнение. Хотя такой подход теоретически выглядит привлекательно, он перечеркивает одно из самых больших преимуществ технологии ASP: возможность быстро создавать приложения и оперативно вносить изменения. Если весь программный код и код HTML заключен в COM-объекты, то при замене любого дескриптора HTML в приложении приходится повторно компилировать и вновь развертывать COM-объекты. По мнению авторов, самая важная проблема связана с использованием этого подхода. COM-объекты представляют собой библиотеки DLL (Dynamic Link Library - динамически загружаемая библиотека), которые загружаются сервером IIS в ходе выполнения программы. После загрузки библиотека не может быть заменена. Для развертывания COM-объекта разработчик должен остановить сервер IIS, завершить работу пакетов MTS, в которых используется COM-объект, заменить его, а затем перезапустить сервер IIS. Здесь фактически описаны далеко не все этапы процесса, но вполне очевидно, какие проблемы связаны с применением такого подхода. Web-сервер приходится останавливать при развертывании каждой новой версии! Время простоя Web-узла при использовании такого подхода можно свести к минимуму, создавая Web-кластеры и последовательно проводя обновление программного обеспечения на серверах кластера; но если Web-кластер достаточно велик, то даже простое изменение может потребовать работы буквально в течение нескольких часов для расстановки новых версий объектов по библиотекам DLL в процессе развертывания приложения.

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

Для развертывания новой версии приложения достаточно скопировать его программные сборки в подкаталог /bin корневого каталога приложения. Среда ASP.NET обнаруживает, что старая версия перекрыта новой, выгружает старую версию и загружает новую! Для развертывания достаточно выполнить команду XCOPY /S или использовать рекурсивную операцию передачи данных по FTP (File Transfer Protocol - протокол передачи файлов) для выгрузки новых файлов на Web-сервер. Дополнительная информация по этой теме приведена в главе 6, "Настройка конфигурации и развертывание".

Настройка конфигурации

Ранее вся информация о конфигурации платформы ASP хранилась в составе метабазы IIS, которая представляла собой двоичный файл, аналогичный по своему назначению системному реестру, который хранил все параметры настройки для IIS и ASP. Для внесения изменений предусматривалось только применение программы диспетчера служб Internet Services Manager или разработка сценариев автоматического внесения изменений с использованием интерфейсов ADSI (Active Directory Services Interface - интерфейс служб активных каталогов). Этот процесс в значительной степени усложнял задачу синхронизации параметров настройки многочисленных серверов в Web-кластере.

В инфраструктуре ASP.NET реализован новый принцип хранения всех параметров настройки. Теперь параметры настройки не хранятся в непрозрачной метабазе, требующей применения специальных средств доступа, а размещаются в иерархическом наборе файлов конфигурации XML. Эти файлы располагаются в корневом каталоге приложения и его подкаталогах. Поэтому теперь при использовании разработчиком команды XCOPY для развертывания файлов исходного кода развертываются и файлы с параметрами настройки! Разработчикам больше не нужно создавать целый комплект сценариев настройки конфигурации. Дополнительная информация об этом приведена в главе 6 , "Настройка конфигурации и развертывание".

Управление состоянием

Управление состоянием в инфраструктуре ASP.NET было значительно улучшено. Теперь на сервере может использоваться один из трех режимов хранения информации о состоянии. Одним из них является традиционный метод хранения в оперативной памяти информации о состоянии отдельного сервера, который впервые был реализован в версии ASP 3.0. Кроме того, в ASP.NET может применяться внепроцессный сервер состояний, а также предусмотрен режим долговременного хранения информации о состоянии на сервере SQL Server.

Одним из ограничений служб поддержки информации о состоянии в инфраструктуре ASP.old являлось то, что для восстановления информации о состоянии пользовательских сеансов после повторного подключения пользователей применялись только cookie-файлы. В инфраструктуре ASP.NET предусмотрена возможность поддерживать информацию о состоянии без использования cookie-файлов; при этом для выборки информации о состоянии после подключения пользователя применяется URL, приведенный в канонической форме. Дополнительные сведения даны в главе 5, "Управление состоянием и кэширование".

Кэширование

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

Если данные изменяются относительно редко, то одним из возможных решений этой проблемы является кэширование. В инфраструктуре ASP.NET предусмотрены две формы кэширования. Кэширование вывода предусматривает получение всей страницы и запись результатов выполнения содержащегося в ней кода в оперативной памяти для последующей доставки. Кэширование данных предусматривает получение элементов, таких как наборы данных, для создания которых требуются большие затраты, и кэширование их на сервере. Дополнительная информация приведена в главе 5, "Управление состоянием и кэширование".

Отладка

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

В технологии ASP.NET не только усовершенствованы средства дистанционной отладки и обеспечено их единообразное использование, но также предоставляется новое средство трассировки Trace, которое может с успехом применяться для обработки той информации, для которой раньше предусматривалось ведение журналов или использовались операторы Response.Write. Дополнительная информация по этой теме приведена в главе 4, "Отладка приложений ASP.NET".

Доступность

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

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

Об авторах

Джеффри П. Макманус (Jeffrey P. McManus) - разработчик и технический писатель, специализирующийся на инструментальных средствах Microsoft. Он в основном занимается разработкой интерактивных приложений с использованием средств Internet и технологии клиент/сервер. Джеффри - автор четырех книг по базам данных и компонентным технологиям; в частности, им была выпущена книга Database Access with Visual Basic 6, которая пользуется большим спросом у читателей. Он регулярно выступает на конференциях VBITS/VSLive, European DevWeek и VBConnections.

Крис Кинсмен (Chris Kinsman) - разработчик и технический писатель, который также специализируется на инструментальных средствах Microsoft. Он участвовал в разработке нескольких Web-узлов с высоким трафиком, основанных полностью на инструментальных средствах Microsoft, и занимал должность вице-президента по программным технологиям компании DevX.com. Кроме того, Крис уже свыше 10 лет консультирует представителей 500 наиболее преуспевающих компаний (Fortune 500) во всем мире по различным вопросам, связанным с применением технологий Visual Studio и Back Office корпорации Microsoft для решения насущных производственных задач. Крис регулярно читает доклады на конференциях VBITS/VSLive, Web Builder и SQL2TheMax.

О технических редакторах

Джавахар Пуввала (Jawahar Puvvala) работает в компании Synapse Integrated Technology на должности старшего разработчика. Он активно участвовал в проектировании и разработке нескольких систем, поэтому глубоко изучил технологии .NET и Java. Джавахар получил две степени бакалавра и является обладателем сертификатов MCSD, MCSE и MCDBA. Он имеет большой опыт исследовательской работы и написал несколько статей для конференций и журналов.

Фил Сайм (Phil Syme) занимается программированием на языках C++ и Visual Basic, начиная с выпуска Windows 3.1. Он внес большой вклад в реализацию нескольких проектов, разработанных с использованием технологии Microsoft для компаний Fortune 100, и был соавтором двух статей, опубликованных на симпозиумах IEEE (Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). В 1995 году Фил закончил университет Карнеги-Меллона со степенью бакалавра по информатике. Фил был соавтором недавно изданных книг: Sams Teach Yourself C# Web Programming in 21 Days (2002 год, ISBN 0-672-32235-8) и Sams Teach Yourself Visual Basic .NET Web Programming in 21 Days (2002 год, ISBN 0-672-32236-6).

Крис Тибодо (Chris Thibodeaux), обладатель сертификатов MCSE+I, MCDBA и MCSD, является главным консультантом управленческой и технологической консультативной компании Empowering Solutions из Южной Калифорнии. Он обладает большим опытом в области системного программирования и баз данных. Крис читает в местном колледже лекции по защите данных в Internet и в локальной сети, а также по архитектуре баз данных SQL. Вы можете с ним связаться по адресу электронной почты [email protected].

Copyright © 1992-2019 Издательская группа "Диалектика-Вильямс"