На переднем крае

Изучение ASP.NET 4.0 — веб-форм и Далее

Дино Эспозито (Dino Esposito)

ASP.NET является стабильным и квалифицированная платформой для создания насыщенных и мощные веб-приложений, поэтому трудно представить новый набор привлекательных функций добавлен на нее. Но последнего осенью с выпуском пакета обновления 1 (SP1) для ASP.NET 3.5, Microsoft уточнение встроенная поддержка AJAX на платформу и расширенные его производительность элементами доставки динамических данных, новой платформы компонентов, предназначенных специально для потребностей управляемые данными и ввода данных приложений.

Параллельно корпорация Майкрософт разработала новехонькие, альтернативная модель программирования называется ASP.NET MVC. В отличие от классической модели веб-форм ASP.NET MVC помогает разработчикам создавать веб-приложений в соответствии с широко распознанный шаблон: Контроллер представление модели.
В настоящее время общей платформы ASP.NET состоит из нескольких различных компонентов: Web Forms и ASP.NET MVC, динамических данных элементов управления ASP.NET AJAX. Предстоящие платформы ASP.NET 4.0 имеет же основу последней версией 3.5 SP1, но он предоставляет дальнейшего усовершенствования в областях Web Forms, элементы управления динамических данных, но не менее последнего ASP.NET AJAX.

В этой статье я расскажу взгляд на такое новые и улучшенные в модели веб-форм. В последующих столбцах ЛИ вам адрес платформы управления динамических данных в целом и просматривать подробные разработок в среде ASP.NET AJAX.

ASP.NET Forms 4.0 с первого взгляда

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

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

Более контроле над событие просмотра состояния

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

Студенты своевременно отметить дополнительной работы, необходимой для заполнения списка в каждое действие сервера. Не удалось это автоматически заполняться в Web? Ну в веб-форм ASP.NET не требуется пополнения элементы управления привязки данных через обратную передачу только из-за событие просмотра состояния.

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

Как широко известен, но также во многом пропущен, событие просмотра состояния является дополнительная возможность. Поддержки состояние отображения включено для каждой страницы по умолчанию, но разработчикам иметь логическое свойство изменить значение по умолчанию и без него. Свойство называется EnableViewState и определен для класса System.Web.UI.Control. Следует отметить, что класс System.Web.UI.Page наследует из класса элемента управления. Насколько точки зрения событие просмотра состояния отдельного элемента управления и страницы являются одно и то же.

Для любой страницы ASP.NET отключение событие просмотра состояния невозможно проще. Установить EnableViewState значение false декларативно или программно во время жизненного цикла на страницу следующим образом:

void Page_Load(object sender, EventArgs e)
{

msdn magazine
2
Cutting Edge
// Disable viewstate for the page
// and ALL of its child controls
this.EnableViewState = false;
...
}

Свойство EnableViewState указывает, разрешено ли элемент управления кэша собственное состояние, связанных с пользовательского ИНТЕРФЕЙСА. Напоминание, параметр состояние представления в ASP.NET имеет иерархической характера, это означает, что если событие просмотра состояния включена на родительский элемент управления, он не может быть отключен на всех его дочерних элементов управления. В следующем примере кода не влияет на поведение текстовое поле, если событие просмотра состояния включен на уровне страницы или контейнера:

protected void Page_Load(object sender, EventArgs e)
{
TextBox1.EnableViewState = false;
}

Свойство IsViewStateEnabled--защищенное свойство действительно--сообщает о текущем состоянии состояние отображения для элемента управления. Но что все это означает для разработчиков?

Если событие просмотра состояния включена на странице (это значение по умолчанию), отсутствуют средства для сохранения состояния отдельных элементов управления Отключение хранилища. Чтобы получить некоторые контроль над системой в ASP.NET 3.5, необходимо отключить состояние представления на уровне страницы и затем включить ее там, где требуется, но также хранить в иерархическую природу его существенной. Любой элемент управления контейнером, который имеет состояние отображения включено будет неизбежно свалить его установка в список своих дочерних элементов. Этот факт ведет к несколько paradox: Возможна ситуация, одного элемента управления, свойство EnableViewState значение false и свойством, IsViewStateEnabled равным true!

Событие просмотра состояния — фундаментальную часть архитектура ASP.NET Web Forms и удаление полностью из платформы имя увеличение производительности возможно не самый лучший вариант. Лет доказало, что более Экологически безопасная параметр испытывает состояние отображения, отключенные по умолчанию на странице. Еще лучше, чем изменение придумать ASP.NET 4.0: Включение контролировать состояние отображения отдельных элементов управления.
В ASP.NET 4.0 класс System.Web.UI.Control предоставляет новое свойство с именем ViewStateMode:

public virtual ViewStateMode ViewStateMode { get; set; }

Свойство принимает его подходящие значения из типа перечисление ViewStateMode, показанного на рис. 1.

Чтобы сохранить совместимость, значение по умолчанию свойство — наследовать. Однако это свойство дает разработчикам возможность управление значение состояния отображения для отдельных элементов управления, независимо от состояния представления вариант любой родительскую страницу или контейнеры.

Только несколько элементов управления в страницах ASP.NET действительно нужен состояния представления. Например все текстовые поля, позволяет просто собрать текст не вообще нужно состояния представления. Если текст является единственным свойством, используется в элементе управления, затем значение свойства Text будет сохраняться по обратной межстраничной передачи из-за разнесенным значениям. Любое значение в состояние представления, на самом деле, будут регулярно заменены разнесенное значение. В этом случае событие просмотра состояния является действительно ненужные. Но есть несколько Обратите внимание. Все стороны свойства, значение определенного значения по умолчанию при создании, но остаются неизменными во время обратной передачи (такие как ReadOnly, BackColor и т. д.) не требуются для перехода к событие просмотра состояния. Например элемент управления Button, сохраняет все время одинаковую подпись не вообще нужно событие просмотра состояния. До ASP.NET 4.0 отключение состояния представления для отдельных элементов управления был проблематичным. В следующей версии изменить вещи. Это ключ takeaway ViewStateMode свойство.

Более контроле над автоматически создаваемые идентификаторы

На страницах ASP.NET используя тот же код для двух серверных элементов управления не разрешено. Если это произойдет, не компилировать страницу--периода. В формате HTML Однако возможна два или более элементов совместно использовать тот же идентификатор. В этом случае при выполнении поиска элемента через document.getElementById вы просто получите массив элементов DOM. Как насчет вложенные элементы управления ASP.NET?

Большинство элементов управления привязкой к данным, основанных на шаблонах создают выходные данные, повторив шаблон HTML для каждого элемента привязкой к данным. Это означает, что любой дочерний элемент управления определен с уникальным ИДЕНТИФИКАТОРОМ в шаблоне повторяется несколько раз. Исходный код просто не быть уникальным. По этой причине с момента начала, команде ASP.NET определенный алгоритм убедитесь, что каждый элемент HTML, созданный элементом управления ASP.NET может иметь уникальный идентификатор. Идентификатор полученным в результате объединение идентификатор элемента управления с ИДЕНТИФИКАТОРОМ в контейнере именования. Кроме того в случае возникновения повторяющихся элементов управления (то есть шаблоны), для устранения неоднозначности добавлен числовой индекс. Для лет никто не действительно cared о удобочитаемость автоматически сгенерированный код и стало довольно часто строки следующим образом:

ctl00$ContentPlaceHolder1$GridView11$TextBox1

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

var btn = document.getElementById("<% =Button1.ClientID %>");

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

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

Теперь класс System.Web.UI.Control возможности совершенно новое свойство с именем ClientIDMode. Свойство может принимать несколько предопределенных значений, как описано на рис. 2.

Надо признать, алгоритм генерации КОДА, особенно когда задействованы главных страниц, не простых для понимания. Для создания уникальных идентификаторов, но заканчивается до со строками, которые действительно трудно предсказать гарантируется. Главным образом для использования с элементы управления с привязкой к данным, так что разработчики могут легко догадаться идентификатор, скажем, элемент управления Label используется для отрисовки заданное свойство элемента данных nth представлены более предсказуемой параметр. В этом случае требуется идентификатор для отражения иерархии элемента управления (упрощение структуре контейнера, имен родительских элементов управления), но также определенного значения ключа, такого как первичный ключ. Рассмотрим следующий код:

<asp:GridView ID="GridView1" runat="server"
ClientIDMode="Predictable"
RowClientIdSuffix="CustomerID">
...
</asp:GridView>

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

Panel1_GridView1_ALFKI_1

GridView — это единственный элемент управления для поддержки нескольких столбцов. При наличии нескольких столбцов для сцепления, затем используется запятой для разделения имен. ListView будет принимать только один столбец, тогда как элемент управления Repeater будет ограничено аудита индекс, основанный на 0 и не принимают имя столбца.

Наконец Обратите внимание, свойство ClientIDMode влияет на только атрибут ID элемента результирующий HTML. По умолчанию атрибут name остается неизменным.

Усовершенствования управления представления

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

В ASP.NET 4.0 текущее выделение в элемент управления с привязкой данных отслеживается через значение в поле ключа данных, можно указать через свойство DataKeyNames. Чтобы включить эту функцию, используйте новое свойство PersistSelection Boolean и значение true. Значение по умолчанию равно false в целях совместимости.

Кроме того элементы управления FormView и ListView предлагают немного лучше контролировать их созданной разметки HTML. В частности FormView теперь учетных записей для новой RenderTable логические свойства. Если задано значение false (значение по умолчанию — true), затем нет лишних выдачи теги таблицы HTML и общей разметки будет проще стиля посредством CSS. ListView больше не нужна шаблон макета в ASP.NET 4.0:

<asp:ListView ID="ListView1" runat="server">
<ItemTemplate>
<% Eval("CompanyName")%>
<hr />
</ItemTemplate>
</asp:ListView>

Предыдущий фрагмент кода является достаточным для повторите содержимое столбца CompanyName для каждого элемента в источнике данных.

Расширения HTML

В начале, ASP.NET не предоставляют гораздо программный контроль за все возможные теги веб-страницы. В течение длительного времени название страницы пропущенных нерегламентированных свойство в классе страницы. Же может быть сказал для других популярных функций, как файлы CSS.

В ASP.NET 4.0 класс страницы предоставляет два новых свойства строки позволяет задать некоторые распространенные теги в < заголовок >раздел на странице. Два новых свойства являются ключевые слова и описание. Содержимое этих свойств сервера будет заменять любое содержимое, возможно сообщили metatags как литералы HTML.

Ключевые слова и описание свойства также могут быть заданы как атрибуты директивы @ Page, как в следующем примере:

<%@ Page Language="C#"
AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
Keywords="ASP.NET, AJAX, 4.0"
Description="ASP.NET 4.0 Web Forms" %>

В ASP.NET вызова Response.Redirect, вы вернетесь в обозревателе кода HTTP 302, что означает, что запрошенному содержимому доступна теперь из другого расположения (указано). Основе, обозреватель выполняет второй запрос по указанному адресу и вот. Механизм поиска, посещении страницы, однако требует кода HTTP 302 буквально. Это фактические означает код состояния HTTP 302, что запрошенная страница временно перемещен на новый адрес. В результате поисковые системы не обновляют свои внутренние таблицы и когда пользователь щелкает для просмотра вашей страницы, обработчик возвращает исходный адрес. Затем обозреватель получает код HTTP 302 и делает второй запрос на наконец отображение нужную страницу.

Чтобы сгладить весь процесс, в ASP.NET 4.0, можно использовать совершенно новый перенаправьте метод, называемый RedirectPermanent. Используйте метод таким же образом использовать классический Response.Redirect за исключением того, что на этот раз вызывающий объект получает код состояния HTTP 301. Код 301 фактически означает, что запрошенному содержимому перемещен окончательно. Для обозревателя не делает большая разница, но это ключевое различие поисковые системы.

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

Дополнительные контроль над выходное кэширование

В ASP.NET 2.0 нескольких основных частей среды ASP.NET были оптимизации и гораздо более гибкой и настраиваемые. Это было достигнуто до введения модель поставщика. Функциональные возможности некоторых служб ядра ASP.NET, включая состояние сеанса, членства и управления ролями были абстрагируется рода сервисного контракта, что разные реализации данной службы могут использоваться попеременно и администраторов может означать того, они хотели из файла конфигурации.

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

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

Существует множество ситуаций, где допустимо для ответа страницы, быть немного устаревшей Если это приносит значительные преимущества. Представить приложение электронной коммерции и его набора страниц каталога продуктов, например. Эти страницы являются относительно ресурсоемкими, создать, поскольку они могут потребовать одного или нескольких вызовов базы данных и скорее всего некоторые форме данных соединения. Страницы продукта стремятся остаются неизменными для недель и редко обновляются несколько раз в день. Почему следует можно восстановить той же странице сотни раз в секунду? Со времен ASP.NET 1.0 кэширования позволяет ответы страницы кэша, следующие запросы могут быть удовлетворен, возвращая кэшированный вывод вместо выполнения страницы. На рис. 3 показана последовательность событий приложения, включая шаг, при котором система пытается разрешить запрос поиском в кэше выходных данных.

До сих выходные данные страницы (которые могут быть сгруппированы по форме и запрос параметры строки, запрашивает URL-адрес или пользовательских строк) хранятся в памяти в частной области кэш ASP.NET. В долгосрочной перспективе объем кэша вывода помещает дополнительную нагрузку на компьютере сервер Web, использование памяти и создания часто обновлять объект кэша. В ASP.NET 4.0 кэширования подсистему полностью вывода поддерживает модель поставщика, тем самым предоставляя разработчикам возможность хранения ответы страницы за пределами поставщика кэш ASP.NET рабочих process.A пользовательский вывод класс, производный от OutputCacheProvider. Имя класса должен быть зарегистрирован в файле конфигурации, как показано ниже:

<caching>
<outputCache defaultProvider="AspNetInternalProvider">
<providers>
<add name="DiskCacheProvider"
type="Samples.DiskCacheProvider, MyProvider"/>
</providers>
</outputCache>
</caching>

Как обычно имеют несколько поставщиков, зарегистрированных и выберите по умолчанию через атрибут defaultProvider на узле outputCache. Поведение по умолчанию предлагается через объект AspNetInternalProvider, оказывается поставщика по умолчанию, если не изменить что-либо в файле конфигурации.

Поставщик кэш вывода не должен быть одинаковым для всех страниц. Можно выбрать другого поставщика для каждого запроса или даже для определенного пользовательского элемента управления, странице или комбинации параметров для страницы. Можно указать имя поставщика в директиве @ OutputCache везде, где принимается эта директива (элементы управления страницы или пользователя):

<% @OutputCache Duration="3600"
VaryByParam="None"
providerName="DiskCache" %>

Чтобы изменить поставщика для каждого запроса, вместо этого необходимо переопределить новый метод global.asax, как показано ниже:

{
// Decide which provider to use looking at the request
string providerName = ...;
return providerName;
}

Начиная с версии 2.0, состояние сеанса может быть сохранен вне памяти рабочего процесса. Это значит, данные, хранящиеся в объект сеанса должны быть сериализованы в и из среды-out of process. Если снова взглянуть на рис. 3, состояние сеанса загружается в объект сеанса вокруг события приложения AcquireRequestState. Затем содержимое в памяти сериализуется обратно в хранилище в конце обработки запроса.
ASP.NET 4.0 позволяет разработчикам запрашивать некоторые сжатия для потока данных, отправляемых и вне сеанса поставщика (см. рис. 4). Сжатие получен с помощью класса GZipStream вместо обычного класса Stream для выполнения любой сериализации:

<sessionState mode="SqlServer" compressionEnabled="true" ... />

Чтобы включить сжатие, просто добавить атрибут compressionEnabled в разделе sessionState файла конфигурации. Сжатие не включена по умолчанию.

Любая библиотека JavaScript состоит из множество определенные файлы JavaScript с более или менее сложный график interconnections. ASP.NET AJAX, вместо этого всегда попытка абстрагируют подробности JavaScript подальше от разработчиков и предлагается вместо объединенный клиента библиотеки JavaScript, через элемент управления ScriptManager. Это изменит в ASP.NET 4.0. Клиентская библиотека Microsoft AJAX была реструктурирована и разбита на отдельные файлы, перечисленные в рис. 5. На рис. 6 показаны зависимости между отдельными файлами сценария в общей библиотеке.

Новое свойство был добавлен в элемент управления ScriptManager, позволяет указать, как должны обрабатываться строительными блоками в библиотеку. Свойство является MicrosoftAjaxMode и принимает значения, как показано на рис. 7.

Улучшения платформы

Веб-форм ASP.NET 4.0 содержит ряд небольших изменений, взятые вместе, сделать его улучшения платформы разработки. Веб-формы — квалифицированная структура, которая требует уточнения не модернизировать. Если не считаете полностью удобно с помощью веб-форм и ищете нечто совершенно ASP.NET MVC будет стоит более тщательного вида.

Дино Эспозито (Dino Esposito) — архитектор в компании IDesign и соавтор книги "Microsoft .NET: Создание архитектуры приложений для предприятия"(Microsoft Press, 2008). Основанная в Италии, Эспозито часто выступает на отраслевых мероприятиях по всему миру. Можете присоединиться к его блогу, посетив weblogs.asp.net/despos.