Язык программирования С# 2005 и платформа .NET 2.0.

Наконец, если требуется наивысшая степень изолированности и устойчивости дли Web-приложения, вы можете "заставить" среду выполнения сохранять все данные состояния сеанса в Microsoft SQL Server. Соответствующая модификация файла Web.config снова очень проста.

‹sessionState mode="SQLServer" stateConnectionString="tcpip=l27.0.0.1:42424" sqlConnectionString="data sourse=127.0.0.1;Trusted_Connection=yes'' cookieless="false" timeout="20" /›

Однако перед тем как вы попытаетесь выполнять соответствующее Web-приложение, вы должны обеспечить правильную настройку целевой машины (указанной атрибутом sqlConnectionString). При установке .NET Framework 2.0 SDK (или Visual Studio 2005) создаются два файла, InstallSqlState.sql и UninstallSqlScate.sql, которые по умолчанию помещаются в папку ‹%windir%›\Microsoft.NET\Framework\‹версия›. На целевой машине вы должны выполнить файл InstallSqlState.sql, используя, например, SQL Server Query Analyzer (который входит в поставку Microsoft SQL Server).

После выполнения указанного SQL-сценария, вы обнаружите новую базу данных SQL Server (с именем ASPState), содержащую набор хранимых процедур, вызываемых средой выполнения ASP.NET, и множество таблиц, используемых для хранения сеансовых данных (кроме того, в базу данных tempdb будет добавлено множество таблиц для обмена данными). Вы должны понимать, что настройка Web-приложения на запоминание сеансовых данных рамках SQL Server является самым медленным из всех возможных вариантов. Преимущество этого варианта в том, что пользовательские данные при этом сохраняются наиболее надежно (даже при перезапуске Web-сервера).

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

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

В завершение этого раздела главы следует упомянуть тот факт, что 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. Этот файл является наивысшим в иерархии наследования конфигурации.