Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Замечание.Если для хранения сеансовых данных используется сервер состояния сеанса ASP.NET или SQL Server, то любой пользовательский тип, размещаемый в объекте HttpSessionState, должен быть обозначен атрибутом [Serializable].

В завершение этого раздела главы следует упомянуть тот факт, что ASP.NET 2.0 теперь предлагает Web-утилиту конфигурации для управления множеством установок в файле Web.config узла. Чтобы активизировать эту утилиту (рис. 24.11), выберите Web Site→ASP.NET Configuration из меню Visual Studio 2005.

Рис. 24.11. Утилита администрирования узла ASP.NET 2.0

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

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

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

Рис. 24.12. Наследование конфигурации

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

Замечание. Вспомните из плавы 11, что файл machine.config определяет различные установки на уровне машины, многие из которых связаны с ASP.NET. Этот файл является наивысшим в иерархии наследования конфигурации.

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

Замечание.Если вам требуется более глубоко изучить ASP.NET 2.0, обратитесь к книге Мэтью Мак-Дональда и Марио Шпушта, Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов (ИД "Вильямс", 2006 г.).

В завершение нашего путешествия в последней главе будет рассмотрена тема создания Web-сервисов XML в .NET 2.0.

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

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

Глава 18 информировала вас о слое удаленного взаимодействия .NET. Вы смогли убедиться в том, что эта технология позволяет любой группе компьютеров с поддержкой .NET осуществлять обмен информацией через границы машин. Это, конечно, прекрасно, но одним из ограничений слоя удаленного взаимодействия .NET оказывается то, что для каждой из участвующих в обмене сторон требуется установка .NET Framework, поддержка CTS и использование одинакового формата сетевого обмена (например, TCP).

Web-сервисы XML предлагают более гибкую альтернативу в деле построения распределенных приложений. Говоря простыми словами, Web-cepвuc XML - это единица программного кода, обслуживаемая Web-сервером и доступная в рамках стандартных промышленных технологий, например, таких как HTTP и XML. Вы, наверное, догадываетесь, что благодаря использованию "нейтральных" технологий Web-сервисы XML предлагают такой уровень совместимости и взаимодействия в отношении операционных систем, платформ и языков, который ранее был просто недоступен.

Из этой последней главы книга вы узнаете о том, как создаются Web-сервисы XML в рамках платформы .NET. В процессе обсуждения основной темы мы рассмотрим также ряд связанных вопросов, в частности службы поиска (UDDI и DISCO), язык WSDL и протокол SOAP. Выяснив, как строить Web-сервисы XML, мы рассмотрим различные возможности генерирования агентов клиента, способных вызывать "Web-методы" в синхронном и асинхронном режимах.

С точки зрения самого высокого уровня вы можете определить Web-сервис XML, как единицу программного кода, доступную для вызова с помощью HTTP-запросов. Однако, в отличие от традиционного Web-приложения, Web-сервисы XML можно использовать не только для того, чтобы возвращать браузеру HTML-код с целью визуализации. Скорее наоборот, Web-сервис XML чаще всего предоставляет функциональные возможности, аналогичные возможностям стандартной библиотеки программного кода .NET (например, специальные вычисления, выборку данных из DataSet, чтение цен на акции и т.д.).

На первый взгляд, Web-сервисы XML могут показаться просто очередной новой технологией удаленного взаимодействия. Это, конечно, так и есть, но давайте рассмотрим эту технологию чуть подробнее. Исторически для доступа к удаленным объектам всегда требовались специальные зависящие от платформы (a часто и от языка) протоколы (DCOM, Java RMI и т.д). Проблема такого подхода заключается не в лежащей в его основе технологии, а в том, что каждая из сторон замыкается в своем специфическом сетевом формате. Поэтому при попытке построения распределенной системы, в которой используется множество операционных систем, каждой машине приходится согласовывать формат пакета данных, протокол передачи и т.д. С целью упрощения ситуации Web-сервисы XML позволяют вызывать методы и свойства удаленного объекта с помощью стандартных HTTP-запросов. Из всех протоколов, существующих на сегодняшний день, HTTP является единственным сетевым протоколом, с которым "согласны" все платформы (в конце концов, HTTP – это основа World Wide Web).