Обзор ASP.NET 4 и Visual Studio 2010 для веб-разработки
В этом документе представлен обзор многих новых функций для ASP.NET, включенных в the.NET Framework 4 и Visual Studio 2010.
Contents
Основные службы
Web.config файл рефакторинг
Расширяемое кэширование выходных данных
Автоматический запуск веб-приложений
Постоянное перенаправление страницы
Сжатие состояния сеанса
Расширение диапазона допустимых URL-адресов
Расширяемая проверка запросов
Кэширование объектов и расширяемость кэширования объектов
Расширяемая кодировка HTML, URL-адреса и заголовка HTTP
Мониторинг производительности для отдельных приложений в одном рабочем процессе
Многонацелие
Ajax
jQuery в составе веб-формы и MVC
Поддержка сети доставки содержимого
Явные скрипты ScriptManager
веб-формы
Настройка метатегов с помощью свойств Page.MetaKeywords и Page.MetaDescription
Включение состояния представления для отдельных элементов управления
Изменения возможностей браузера
Маршрутизация в ASP.NET 4
Настройка идентификаторов клиентов
Сохранение выделения строк в элементах управления данными
Фильтрация данных с помощью элемента управления QueryExtender
Выражения кода в кодировке HTML
Изменения шаблона проекта
Улучшения CSS
Скрытие элементов div вокруг скрытых полей
Отрисовка внешней таблицы для шаблонных элементов управления
Улучшения элемента управления ListView
Улучшения элементов управления CheckBoxList и RadioButtonList
Улучшения элемента управления меню
Мастер и CreateUserWizard Controls 56
ASP.NET MVC
Поддержка областей
Поддержка проверки атрибутов примечаний к данным
Шаблонные вспомогательные функции
Динамические данные
Включение динамических данных для существующих проектов
Декларативный синтаксис элемента управления DynamicDataManager
Шаблоны сущностей
Новые шаблоны полей для URL-адресов и адресов электронной почты
Создание ссылок с помощью элемента управления DynamicHyperLink
Поддержка наследования в модели данных
Поддержка связей "многие ко многим" (только Entity Framework)
Новые атрибуты для управления отображением и поддержкой перечислений
Расширенная поддержка фильтров
Улучшения веб-разработки в Visual Studio 2010
Улучшенная совместимость CSS
Фрагменты кода HTML и JavaScript
Улучшения IntelliSense для JavaScript
Развертывание веб-приложений с помощью Visual Studio 2010
Веб-упаковка
Развертывание базы данных
Публикация одним щелчком для веб-приложений
Ресурсы
Основные службы
ASP.NET 4 представлен ряд функций, которые улучшают основные службы ASP.NET, такие как кэширование выходных данных и хранилище состояний сеансов.
Рефакторинг файлов Web.config
ФайлWeb.config, содержащий конфигурацию для веб-приложения, значительно вырос за последние несколько выпусков платформа .NET Framework по мере добавления новых функций, таких как Ajax, маршрутизация и интеграция со СЛУЖБАми IIS 7. Это усложняет настройку или запуск новых веб-приложений без такого средства, как Visual Studio. В .NET Framework 4 основные элементы конфигурации были перемещены в machine.config файл, и приложения теперь наследуют эти параметры. Это позволяет файлу Web.config в ASP.NET 4 приложений быть пустым или содержать только следующие строки, которые указывают для Visual Studio, на какую версию платформы предназначено приложение:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation targetFramework="4.0" />
</system.web>
</configuration>
Расширяемое кэширование выходных данных
С момента выпуска ASP.NET 1.0 кэширование выходных данных позволило разработчикам хранить созданные выходные данные страниц, элементов управления и HTTP-ответов в памяти. При последующих веб-запросах ASP.NET могут быстрее обслуживать содержимое, извлекая созданные выходные данные из памяти вместо повторного создания выходных данных с нуля. Однако этот подход имеет ограничение — созданное содержимое всегда должно храниться в памяти, а на серверах с интенсивным трафиком память, потребляемая кэшированием выходных данных, может конкурировать с требованиями к памяти других частей веб-приложения.
ASP.NET 4 добавляет точку расширяемости для кэширования вывода, которая позволяет настроить один или несколько настраиваемых поставщиков кэша вывода. Поставщики кэша вывода могут использовать любой механизм хранения для сохранения содержимого HTML. Это позволяет создавать настраиваемые поставщики кэша вывода для различных механизмов сохраняемости, которые могут включать локальные или удаленные диски, облачное хранилище и подсистемы распределенного кэша.
Настраиваемый поставщик кэша вывода создается как класс, производный от нового типа System.Web.Caching.OutputCacheProvider . Затем можно настроить поставщик в Web.config файле с помощью нового подраздела providers элемента outputCache , как показано в следующем примере:
<caching>
<outputCache defaultProvider="AspNetInternalProvider">
<providers>
<add name="DiskCache"
type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
</providers>
</outputCache>
</caching>
По умолчанию в ASP.NET 4 все HTTP-ответы, отрисовываемые страницы и элементы управления используют кэш вывода в памяти, как показано в предыдущем примере, где атрибут defaultProvider имеет значение AspNetInternalProvider. Вы можете изменить поставщик кэша вывода по умолчанию, используемый для веб-приложения, указав другое имя поставщика для defaultProvider.
Кроме того, можно выбрать различных поставщиков кэша вывода для каждого элемента управления и для каждого запроса. Самый простой способ выбрать другой поставщик кэша вывода для различных элементов управления веб-пользователей — сделать это декларативно, используя новый атрибут providerName в директиве управления, как показано в следующем примере:
<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>
Указание другого поставщика кэша вывода для HTTP-запроса требует немного дополнительной работы. Вместо декларативного указания поставщика необходимо переопределить новый метод GetOuputCacheProviderName в Global.asax файле, чтобы программно указать, какой поставщик будет использоваться для конкретного запроса. В приведенном ниже примере показано, как это сделать.
public override string GetOutputCacheProviderName(HttpContext context)
{
if (context.Request.Path.EndsWith("Advanced.aspx"))
return "DiskCache";
else
return base.GetOutputCacheProviderName(context);
}
Благодаря добавлению расширяемости поставщика кэша вывода в ASP.NET 4 теперь можно применять более агрессивные и более интеллектуальные стратегии кэширования вывода для веб-сайтов. Например, теперь можно кэшировать первые 10 страниц сайта в памяти, кэшируя при этом страницы, которые получают меньший трафик на диске. Кроме того, можно кэшировать каждую разную комбинацию для отображаемой страницы, но использовать распределенный кэш, чтобы потребление памяти было выгружено с интерфейсных веб-серверов.
Автоматический запуск веб-приложений
Некоторые веб-приложения должны загружать большие объемы данных или выполнять дорогостоящую обработку инициализации перед обработкой первого запроса. В более ранних версиях ASP.NET для таких ситуаций приходилось разрабатывать пользовательские подходы к "пробуждению" приложения ASP.NET, а затем выполнять код инициализации во время метода Application_Load в Global.asax файле.
Новая функция масштабируемости с именем автозапуск , которая напрямую отвечает этому сценарию, доступна, когда ASP.NET 4 выполняется в IIS 7.5 в Windows Server 2008 R2. Функция автоматического запуска обеспечивает управляемый подход к запуску пула приложений, инициализации ASP.NET приложения и последующему приему HTTP-запросов.
Примечание
Модуль Warm-Up приложений IIS для IIS 7.5
Команда iis выпустила первую бета-тестовую версию модуля Application Warm-Up для IIS 7.5. Это делает прогрев приложений еще проще, чем описано ранее. Вместо написания пользовательского кода необходимо указать URL-адреса ресурсов, которые будут выполняться до того, как веб-приложение примет запросы из сети. Эта прогрева происходит во время запуска службы IIS (если пул приложений IIS настроен как AlwaysRunning) и при перезапуске рабочего процесса IIS. Во время перезапуска старый рабочий процесс IIS продолжает выполнять запросы до тех пор, пока вновь созданный рабочий процесс не будет полностью разогрет, чтобы приложения не испытывали прерываний или других проблем из-за непрямых кэшей. Обратите внимание, что этот модуль работает с любой версией ASP.NET, начиная с версии 2.0.
Дополнительные сведения см. в разделе Прогревать приложения на веб-сайте IIS.net. Пошаговое руководство по использованию функции прогрева см. в разделе начало работы с модулем Warm-Up приложений IIS 7.5 на веб-сайте IIS.net.
Чтобы использовать функцию автозапуска, администратор IIS задает автоматический запуск пула приложений в IIS 7.5 с помощью следующей applicationHost.config конфигурации в файле:
<applicationpools>
<add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationpools>
Так как один пул приложений может содержать несколько приложений, вы указываете отдельные приложения для автоматического запуска с помощью следующей applicationHost.config конфигурации в файле:
<sites>
<site name="MySite" id="1">
<application path="/"
serviceAutoStartEnabled="true"
serviceAutoStartProvider="PrewarmMyCache" >
<!-- Additional content -->
</application>
</site>
</sites>
<!-- Additional content -->
<serviceautostartproviders>
<add name="PrewarmMyCache"
type="MyNamespace.CustomInitialization, MyLibrary" />
</serviceautostartproviders>
При холодном запуске сервера IIS 7.5 или перезапуске отдельного пула приложений IIS 7.5 использует сведения в applicationHost.config файле, чтобы определить, какие веб-приложения необходимо запускать автоматически. Для каждого приложения, помеченного для автоматического запуска, IIS7.5 отправляет запрос на ASP.NET 4, чтобы запустить приложение в состоянии, в течение которого приложение временно не принимает HTTP-запросы. Когда он находится в этом состоянии, ASP.NET создает экземпляр типа, определенного атрибутом serviceAutoStartProvider (как показано в предыдущем примере), и вызывает его общедоступную точку входа.
Вы создаете управляемый тип автозапуска с необходимой точкой входа, реализовав интерфейс IProcessHostPreloadClient , как показано в следующем примере:
public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
public void Preload(string[] parameters)
{
// Perform initialization.
}
}
После выполнения кода инициализации в методе Preload и возврата метода приложение ASP.NET готово к обработке запросов.
Благодаря добавлению автоматического запуска в IIS .5 и ASP.NET 4 теперь у вас есть четко определенный подход к выполнению дорогостоящей инициализации приложений перед обработкой первого HTTP-запроса. Например, можно использовать новую функцию автозапуска, чтобы инициализировать приложение, а затем сообщить подсистеме балансировки нагрузки о том, что приложение инициализировано и готово к приему ТРАФИКА HTTP.
Постоянное перенаправление страницы
В веб-приложениях часто перемещаются страницы и другое содержимое с течением времени, что может привести к накоплению устаревших ссылок в поисковых системах. В ASP.NET разработчики традиционно обрабатывают запросы к старым URL-адресам с помощью метода Response.Redirect для пересылки запроса на новый URL-адрес. Однако метод Redirect выдает ответ HTTP 302 Found (временное перенаправление), что приводит к дополнительному циклу HTTP при попытке пользователей получить доступ к старым URL-адресам.
ASP.NET 4 добавлен новый вспомогательный метод RedirectPermanent , который упрощает выдачу ответов HTTP 301 Перемещено безвозвратно, как показано в следующем примере:
RedirectPermanent("/newpath/foroldcontent.aspx");
Поисковые системы и другие агенты пользователей, которые распознают постоянные перенаправления, будут хранить новый URL-адрес, связанный с содержимым, что исключает ненужные круговые пути, выполняемые браузером для временных перенаправлений.
Сжатие состояния сеанса
ASP.NET предоставляет два варианта хранения состояния сеанса в веб-ферме по умолчанию: поставщик состояний сеансов, который вызывает сервер состояния сеансов вне процесса, и поставщик состояний сеанса, который хранит данные в базе данных Microsoft SQL Server. Так как оба варианта предполагают хранение сведений о состоянии за пределами рабочего процесса веб-приложения, состояние сеанса необходимо сериализовать перед отправкой в удаленное хранилище. В зависимости от того, сколько сведений разработчик сохраняет в состоянии сеанса, размер сериализованных данных может значительно увеличиться.
ASP.NET 4 вводит новый параметр сжатия для обоих типов поставщиков состояний сеансов вне процесса. Если параметр конфигурации compressionEnabled, показанный в следующем примере, имеет значение true, ASP.NET будет сжимать (и распаковывать) сериализованное состояние сеанса с помощью класса платформа .NET Framework System.IO.Compression.GZipStream.
<sessionState
mode="SqlServer"
sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
allowCustomSqlDatabase="true"
compressionEnabled="true"
/>
Благодаря простому добавлению нового атрибута Web.config в файл приложения с резервными циклами ЦП на веб-серверах могут существенно сократить размер сериализованных данных о состоянии сеанса.
Расширение диапазона допустимых URL-адресов
ASP.NET 4 представлены новые параметры для расширения размера URL-адресов приложений. Предыдущие версии ASP.NET ограниченную длину URL-пути до 260 символов на основе ограничения пути к файлу NTFS. В ASP.NET 4 вы можете увеличить (или уменьшить) это ограничение в соответствии с вашими приложениями, используя два новых атрибута конфигурации httpRuntime . В следующем примере показаны эти новые атрибуты.
<httpRuntime maxUrlLength="260" maxQueryStringLength="2048" />
Чтобы разрешить более длинные или короткие пути (часть URL-адреса, которая не включает протокол, имя сервера и строку запроса), измените атрибут maxUrlLength . Чтобы разрешить длинные или короткие строки запроса, измените значение атрибута maxQueryStringLength .
ASP.NET 4 также позволяет настроить символы, используемые символом URL-адреса проверка. Когда ASP.NET находит недопустимый символ в части пути URL-адреса, он отклоняет запрос и выдает ошибку HTTP 400. В предыдущих версиях ASP.NET проверки символов URL-адреса ограничивались фиксированным набором символов. В ASP.NET 4 можно настроить набор допустимых символов с помощью нового атрибута requestPathInvalidCharacters элемента конфигурации httpRuntime , как показано в следующем примере:
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,:,\,?" />
По умолчанию атрибут requestPathInvalidCharacters определяет восемь символов как недопустимые. (В строке, назначенной requestPathInvalidCharacters по умолчанию, кодируются символы меньше (<), больше (>) и амперсанд (&), так как Web.config файл является XML-файлом.) При необходимости можно настроить набор недопустимых символов.
Примечание
Примечание ASP.NET 4 всегда отклоняет пути URL-адресов, содержащие символы в диапазоне ASCII 0x00 0x1F, так как это недопустимые символы URL-адресов, как определено в RFC 2396 IETF (http://www.ietf.org/rfc/rfc2396.txt). В версиях Windows Server, работающих под управлением IIS 6 или более поздней версии, драйвер устройства протокола http.sys автоматически отклоняет URL-адреса с этими символами.
Расширяемая проверка запросов
ASP.NET проверка запроса ищет входящие данные HTTP-запроса на наличие строк, которые обычно используются в атаках межсайтовых сценариев (XSS). При обнаружении потенциальных строк XSS запрос проверки помечает подозрительную строку и возвращает ошибку. Встроенная проверка запроса возвращает ошибку только при обнаружении наиболее распространенных строк, используемых в атаках XSS. Предыдущие попытки сделать проверку XSS более агрессивной приводили к слишком много ложноположительных результатов. Однако клиентам может потребоваться проверка запросов, которая является более агрессивной, или, наоборот, может потребоваться намеренно ослабить проверки XSS для определенных страниц или для определенных типов запросов.
В ASP.NET 4 функция проверки запросов была расширяема, чтобы можно было использовать пользовательскую логику проверки запросов. Чтобы расширить проверку запроса, создайте класс, производный от нового типа System.Web.Util.RequestValidator, и настраиваете приложение (в разделе Web.confighttpRuntime файла) для использования пользовательского типа. В следующем примере показано, как настроить пользовательский класс проверки запросов:
<httpRuntime requestValidationType="Samples.MyValidator, Samples" />
Для нового атрибута requestValidationType требуется стандартная строка идентификатора типа платформа .NET Framework, задающая класс, обеспечивающий проверку настраиваемого запроса. Для каждого запроса ASP.NET вызывает пользовательский тип для обработки каждого фрагмента входящих данных HTTP-запроса. Входящий URL-адрес, все заголовки HTTP (как файлы cookie, так и пользовательские заголовки) и тело сущности доступны для проверки пользовательским классом проверки запроса, как показано в следующем примере:
public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{...}
}
В случаях, когда вы не хотите проверять часть входящих данных HTTP, класс проверки запроса может откатиться, чтобы позволить ASP.NET проверку запроса по умолчанию, просто вызвав base. IsValidRequestString.
Кэширование объектов и расширяемость кэширования объектов
С момента своего первого выпуска ASP.NET включает мощный кэш объектов в памяти (System.Web.Caching.Cache). Реализация кэша настолько популярна, что используется в не веб-приложениях. Однако для приложения Windows Forms или WPF неловко включать ссылку System.Web.dll только для использования кэша объектов ASP.NET.
Чтобы сделать кэширование доступным для всех приложений, платформа .NET Framework 4 представляет новую сборку, новое пространство имен, некоторые базовые типы и конкретную реализацию кэширования. Новая System.Runtime.Caching.dll сборка содержит новый API кэширования в пространстве имен System.Runtime.Caching . Пространство имен содержит два основных набора классов:
- Абстрактные типы, которые обеспечивают основу для создания любого типа реализации пользовательского кэша.
- Конкретная реализация кэша объектов в памяти (класс System.Runtime.Caching.MemoryCache ).
Новый класс MemoryCache тесно смоделирован на основе кэша ASP.NET и использует большую часть логики внутреннего обработчика кэша с ASP.NET. Хотя общедоступные API кэширования в System.Runtime.Caching были обновлены для поддержки разработки пользовательских кэшей, если вы использовали объект ASP.NET Cache , вы найдете знакомые понятия в новых API.
Для подробного обсуждения нового класса MemoryCache и вспомогательных базовых API потребуется целый документ. Однако в следующем примере показано, как работает новый API кэша. Пример был написан для приложения Windows Forms без зависимости от System.Web.dll.
private void btnGet_Click(object sender, EventArgs e)
{
//Obtain a reference to the default MemoryCache instance.
//Note that you can create multiple MemoryCache(s) inside
//of a single application.
ObjectCache cache = MemoryCache.Default;
//In this example the cache is storing the contents of a file string
fileContents = cache["filecontents"] as string;
//If the file contents are not currently in the cache, then
//the contents are read from disk and placed in the cache.
if (fileContents == null)
{
//A CacheItemPolicy object holds all the pieces of cache
//dependency and cache expiration metadata related to a single
//cache entry.
CacheItemPolicy policy = new CacheItemPolicy();
//Build up the information necessary to create a file dependency.
//In this case we just need the file path of the file on disk.
List filePaths = new List();
filePaths.Add("c:\\data.txt");
//In the new cache API, dependencies are called "change monitors".
//For this example we want the cache entry to be automatically expired
//if the contents on disk change. A HostFileChangeMonitor provides
//this functionality.
policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths));
//Fetch the file's contents
fileContents = File.ReadAllText("c:\\data.txt");
//And then store the file's contents in the cache
cache.Set("filecontents", fileContents, policy);
}
MessageBox.Show(fileContents);
}
Расширяемая кодировка HTML, URL-адресов и заголовков HTTP
В ASP.NET 4 можно создавать пользовательские подпрограммы кодирования для следующих распространенных задач кодирования текста:
- Кодирование HTML.
- Кодировка URL-адреса.
- Кодировка атрибута HTML.
- Кодирование исходящих заголовков HTTP.
Вы можете создать пользовательский кодировщик, наследуя от нового типа System.Web.Util.HttpEncoder, а затем настроив ASP.NET для использования пользовательского Web.config типа в разделе httpRuntime файла, как показано в следующем примере:
<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />
После настройки пользовательского кодировщика ASP.NET автоматически вызывает реализацию пользовательского кодирования при каждом вызове открытых методов кодирования классов System.Web.HttpUtility или System.Web.HttpServerUtility . Это позволяет одной из групп разработчиков веб-приложений создать пользовательский кодировщик, который реализует агрессивное кодирование символов, в то время как остальная часть команды разработчиков веб-приложений продолжает использовать общедоступные API кодирования ASP.NET. Централизованная настройка пользовательского кодировщика в элементе httpRuntime гарантирует, что все вызовы с кодировкой текста из общедоступных API кодирования ASP.NET будут направляться через пользовательский кодировщик.
Мониторинг производительности отдельных приложений в одном рабочем процессе
Чтобы увеличить количество веб-сайтов, которые можно разместить на одном сервере, многие хостеры запускают несколько ASP.NET приложений в одном рабочем процессе. Однако если несколько приложений используют один общий рабочий процесс, администраторам сервера сложно определить отдельное приложение, в котором возникают проблемы.
ASP.NET 4 использует новые функции мониторинга ресурсов, появившиеся в среде CLR. Чтобы включить эту функцию, можно добавить следующий фрагмент xml-конфигурации в файл конфигурации aspnet.config .
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<runtime>
<appDomainResourceMonitoring enabled="true"/>
</runtime>
</configuration>
Примечание
Примечание. Файл aspnet.config находится в каталоге, в котором установлен платформа .NET Framework. Это не Web.config файл.
Если функция appDomainResourceMonitoring включена, в категории производительности "приложения ASP.NET" доступны два новых счетчика производительности: % времени управляемого процессора и используемая управляемая память. Оба этих счетчика производительности используют новую функцию управления ресурсами домена приложения CLR для отслеживания предполагаемого времени ЦП и использования управляемой памяти отдельными приложениями ASP.NET. В результате благодаря ASP.NET 4 администраторы теперь имеют более детальное представление о потреблении ресурсов отдельными приложениями, работающими в одном рабочем процессе.
Нацеливание на несколько версий
Вы можете создать приложение, предназначенное для определенной версии платформа .NET Framework. В ASP.NET 4 новый атрибут в элементе компиляцииWeb.config файла позволяет ориентироваться на платформа .NET Framework 4 и более поздних версий. Если вы явно нацелились на платформа .NET Framework 4 и включили в Web.config файл необязательные элементы, например записи для system.codedom, эти элементы должны быть правильными для платформа .NET Framework 4. (Если вы явно не нацеливали платформа .NET Framework 4, целевая платформа выводится из отсутствия записи в Web.config файле.)
В следующем примере показано использование атрибута targetFramework в элементе компиляцииWeb.config файла.
<compilation targetFramework="4.0"/>
Обратите внимание на следующее о выборе конкретной версии платформа .NET Framework.
- В пуле приложений платформа .NET Framework 4 система сборки ASP.NET предполагает, что платформа .NET Framework 4 в качестве целевого объекта, если
Web.configфайл не содержит атрибут targetFramework или файлWeb.configотсутствует. (Может потребоваться внести изменения в код приложения, чтобы оно выполнялось в платформа .NET Framework 4.) - Если включен атрибут targetFramework и в файле определен
Web.configэлемент system.codeDom, этот файл должен содержать правильные записи для платформа .NET Framework 4. - Если вы используете команду aspnet_compiler для предварительной компиляции приложения (например, в среде сборки), необходимо использовать правильную версию команды aspnet_compiler для целевой платформы. Используйте компилятор, поставляемый с платформа .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727), для компиляции для платформа .NET Framework 3.5 и более ранних версий. Используйте компилятор, поставляемый с платформа .NET Framework 4, для компиляции приложений, созданных с помощью этой платформы или более поздних версий.
- Во время выполнения компилятор использует последние сборки платформы, установленные на компьютере (и, следовательно, в GAC). Если позднее будет выполнено обновление платформы (например, установлена гипотетическая версия 4.1), вы сможете использовать функции в более новой версии платформы, даже если атрибут targetFramework предназначен для более ранней версии (например, 4.0). (Однако во время разработки в Visual Studio 2010 или при использовании команды aspnet_compiler использование новых функций платформы приведет к ошибкам компилятора.
Ajax
JQuery входит в состав веб-формы и MVC
Шаблоны Visual Studio для веб-формы и MVC включают библиотеку jQuery с открытым кодом. При создании нового веб-сайта или проекта создается папка Scripts, содержащая следующие 3 файла:
- jQuery-1.4.1.js — удобочитаемая, неопроверенная версия библиотеки jQuery.
- jQuery-14.1.min.js — минифицированная версия библиотеки jQuery.
- jQuery-1.4.1-vsdoc.js — файл документации Intellisense для библиотеки jQuery.
Включите неунижаемую версию jQuery при разработке приложения. Включите минифицированную версию jQuery для рабочих приложений.
Например, на следующей странице веб-формы показано, как с помощью jQuery изменить цвет фона элементов управления TextBox ASP.NET на желтый, если они имеют фокус.
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Show jQuery</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="txtFirstName" runat="server" />
<br />
<asp:TextBox ID="txtLastName" runat="server" />
</div>
</form>
<script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>
<script type="text/javascript">
$("input").focus( function() { $(this).css("background-color", "yellow"); });
</script>
</body>
</html>
Поддержка сети доставки содержимого
Сеть доставки содержимого Microsoft Ajax (CDN) позволяет легко добавлять ASP.NET скрипты Ajax и jQuery в веб-приложения. Например, вы можете начать использовать библиотеку jQuery, просто добавив <script> на страницу тег, указывающий на Ajax.microsoft.com следующим образом:
<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>
Используя преимущества сети Microsoft Ajax CDN, можно значительно повысить производительность приложений Ajax. Содержимое сети CDN Microsoft Ajax кэшируются на серверах, расположенных по всему миру. Кроме того, эта сеть позволяет браузерам повторно использовать файлы JavaScript для веб-сайтов, размещенных в разных доменах.
Сеть доставки содержимого Microsoft Ajax поддерживает ПРОТОКОЛ SSL (HTTPS) на случай, если вам нужно обслуживать веб-страницу с помощью протокола Secure Sockets Layer.
Реализуйте резервный вариант, если СЕТЬ CDN недоступна. Протестируйте резервный вариант.
Дополнительные сведения о сети доставки содержимого Microsoft Ajax см. на следующем веб-сайте:
https://www.asp.net/ajaxlibrary/CDN.ashx
ASP.NET ScriptManager поддерживает microsoft Ajax CDN. Просто задав одно свойство EnableCdn, можно получить все файлы JavaScript платформы ASP.NET из CDN:
<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />
После того как для свойства EnableCdn задано значение true, платформа ASP.NET получит все файлы JavaScript платформы ASP.NET из CDN, включая все файлы JavaScript, используемые для проверки, и UpdatePanel. Установка этого свойства может существенно повлиять на производительность веб-приложения.
Вы можете задать путь CDN для собственных файлов JavaScript с помощью атрибута WebResource. Новое свойство CdnPath указывает путь к СЕТИ CDN, используемой при присвоении свойству EnableCdn значения true:
[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]
Явные скрипты ScriptManager
В прошлом, если вы использовали ASP.NET ScriptManger, вам требовалось загрузить всю монолитную библиотеку ASP.NET Ajax. Используя новое свойство ScriptManager.AjaxFrameworkMode, вы можете точно контролировать, какие компоненты библиотеки ASP.NET Ajax загружаются, и загружать только необходимые компоненты библиотеки ASP.NET Ajax.
Свойство ScriptManager.AjaxFrameworkMode может иметь следующие значения:
- Включено — указывает, что элемент управления ScriptManager автоматически включает MicrosoftAjax.js файл скрипта, который представляет собой объединенный файл скрипта каждого скрипта основной платформы (устаревшее поведение).
- Отключено — указывает, что все функции скриптов Microsoft Ajax отключены и элемент управления ScriptManager не ссылается на скрипты автоматически.
- Явный — указывает, что вы будете явно включать ссылки на скрипты в отдельный файл основного скрипта платформы, который требуется для вашей страницы, и что вы будете включать ссылки на зависимости, необходимые для каждого файла скрипта.
Например, если для свойства AjaxFrameworkMode задано значение Explicit, можно указать конкретные скрипты компонентов Ajax ASP.NET, которые вам нужны:
<asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">
<Scripts>
<asp:ScriptReference Name="MicrosoftAjaxCore.js" />
<asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />
<asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />
<asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />
</Scripts>
</asp:ScriptManager>
веб-формы
веб-формы является основной функцией в ASP.NET с момента выпуска ASP.NET 1.0. В ASP.NET 4 в этой области реализовано множество улучшений, в том числе:
- Возможность установки метатегов .
- Дополнительный контроль над состоянием представления.
- Более простые способы работы с возможностями браузера.
- Поддержка использования маршрутизации ASP.NET с веб-формы.
- Больший контроль над созданными идентификаторами.
- Возможность сохранения выбранных строк в элементах управления данными.
- Дополнительный контроль над отображаемым HTML-кодом в элементах управления FormView и ListView .
- Поддержка фильтрации для элементов управления источником данных.
Настройка метатегов с помощью свойств Page.MetaKeywords и Page.MetaDescription
ASP.NET 4 добавляет два свойства в класс Page : MetaKeywords и MetaDescription. Эти два свойства представляют соответствующие метатеги на странице, как показано в следующем примере:
<head id="Head1" runat="server">
<title>Untitled Page</title>
<meta name="keywords" content="These, are, my, keywords" />
<meta name="description" content="This is the description of my page" />
</head>
Эти два свойства работают так же, как свойство Title страницы. Они следуют следующим правилам:
- Если в элементе head нет метатегов, соответствующих именам свойств (то есть name="keywords" для Page.MetaKeywords и name="description" для Page.MetaDescription, то есть эти свойства не заданы), метатеги будут добавлены на страницу при ее отрисовке.
- Если метатеги с этими именами уже есть, эти свойства действуют как методы get и set для содержимого существующих тегов.
Эти свойства можно задать во время выполнения, что позволяет получать содержимое из базы данных или другого источника, а также динамически задавать теги для описания конкретной страницы.
Вы также можете задать свойства Keywords и Description в директиве @ Page в верхней части разметки страницы веб-формы, как показано в следующем примере:
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
Keywords="These, are, my, keywords"
Description="This is a description" %>
Это переопределит содержимое метатегов (если таковое есть), уже объявленное на странице.
Содержимое мета-тега description используется для улучшения предварительного просмотра списка поиска в Google. (Дополнительные сведения см. в разделе Улучшение фрагментов кода с помощью мета-описания макияжа в блоге Google Webmaster Central.) Google и Windows Live Search не используют содержимое ключевых слов для чего-либо, но другие поисковые системы могут.
Эти новые свойства являются простой функцией, но они избавляют вас от необходимости добавлять их вручную или от написания собственного кода для создания метатегов .
Включение состояния представления для отдельных элементов управления
По умолчанию для страницы включено состояние представления, в результате чего каждый элемент управления на странице потенциально сохраняет состояние представления, даже если оно не требуется для приложения. Данные состояния просмотра включаются в разметку, создаваемую страницей, и увеличивают время, необходимое для отправки страницы клиенту и ее обратной публикации. Хранение большего объема состояния представления может привести к значительному снижению производительности. В более ранних версиях ASP.NET разработчики могли отключить состояние просмотра для отдельных элементов управления, чтобы уменьшить размер страницы, но это было необходимо сделать явно для отдельных элементов управления. В ASP.NET 4 серверные веб-элементы управления включают свойство ViewStateMode , которое позволяет отключить состояние представления по умолчанию, а затем включить его только для элементов управления, которым оно требуется на странице.
Свойство ViewStateMode принимает перечисление с тремя значениями: Enabled, Disabled и Inherit. Включено включает состояние просмотра для этого элемента управления и для всех дочерних элементов управления, для которых задано значение Inherit или для которых ничего не задано. Значение Disabled отключает состояние просмотра, а Inherit указывает, что элемент управления использует параметр ViewStateMode из родительского элемента управления.
В следующем примере показано, как работает свойство ViewStateMode . Разметка и код для элементов управления на следующей странице содержат значения для свойства ViewStateMode :
<form id="form1" runat="server">
<script runat="server">
protected override void OnLoad(EventArgs e) {
if (!IsPostBack) {
label1.Text = label2.Text = "[DynamicValue]";
}
base.OnLoad(e);
}
</script>
<asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled">
Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br />
<asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled">
Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" />
</asp:PlaceHolder>
</asp:PlaceHolder>
<hr />
<asp:button ID="Button1" runat="server" Text="Postback" />
<%-- Further markup here --%>
Как видите, код отключает состояние просмотра для элемента управления PlaceHolder1. Дочерний элемент управления label1 наследует это значение свойства (Inherit — это значение по умолчанию для ViewStateMode для элементов управления) и, следовательно, не сохраняет состояние представления. В элементе управления PlaceHolder2 для параметра ViewStateMode задано значение Enabled, поэтому label2 наследует это свойство и сохраняет состояние представления. При первой загрузке страницы свойству Text обоих элементов управления Label присваивается строка "[DynamicValue]".
Результатом этих параметров является то, что при первой загрузке страницы в браузере отображаются следующие выходные данные:
Отключен : [DynamicValue]
Включен:[DynamicValue]
Однако после обратной передачи отображаются следующие выходные данные:
Отключен : [DeclaredValue]
Включен:[DynamicValue]
Элемент управления label1 (значение ViewStateMode которого имеет значение Disabled) не сохранил значение, заданное в коде. Однако элемент управления label2 (значение ViewStateMode которого имеет значение Enabled) сохранил свое состояние.
Вы также можете задать ViewStateMode в директиве @ Page , как показано в следующем примере:
<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs"
Inherits="WebApplication1._Default"
ViewStateMode="Disabled" %>
Класс Page — это просто еще один элемент управления; он выступает в качестве родительского элемента управления для всех остальных элементов управления на странице. Значение по умолчанию ViewStateMode — Включено для экземпляров Page. Так как элементы управления по умолчанию имеют значение Наследовать, элементы управления наследуют значение свойства Enabled , если вы не задали ViewStateMode на уровне страницы или элемента управления.
Значение свойства ViewStateMode определяет, поддерживается ли состояние представления, только если свойство EnableViewState имеет значение true. Если для свойства EnableViewState задано значение false, состояние представления не будет поддерживаться, даже если параметр ViewStateMode имеет значение Enabled.
Эту функцию можно использовать с элементами управления ContentPlaceHolder на master страницах, где можно задать для параметра ViewStateMode значение Disabled для master страницы, а затем включить его по отдельности для элементов управления ContentPlaceHolder, которые, в свою очередь, содержат элементы управления, требующие состояния просмотра.
Изменения возможностей браузера
ASP.NET определяет возможности браузера, которые пользователь использует для просмотра сайта с помощью функции, называемой возможностями браузера. Возможности браузера представлены объектом HttpBrowserCapabilities (предоставляемым свойством Request.Browser ). Например, можно использовать объект HttpBrowserCapabilities , чтобы определить, поддерживает ли тип и версия текущего браузера определенную версию JavaScript. Или можно использовать объект HttpBrowserCapabilities , чтобы определить, поступил ли запрос с мобильного устройства.
Объект HttpBrowserCapabilities управляется набором файлов определения браузера. Эти файлы содержат сведения о возможностях определенных браузеров. В ASP.NET 4, эти файлы определения браузера были обновлены, чтобы содержать информацию о недавно представленных браузерах и устройствах, таких как Google Chrome, исследования в движении ежевики смартфонов, и Apple iPhone.
В следующем списке показаны новые файлы определения браузера:
- blackberry.browser
- chrome.browser
- Default.browser
- firefox.browser
- gateway.browser
- generic.browser
- ie.browser
- iemobile.browser
- iphone.browser
- opera.browser
- safari.browser
Использование поставщиков возможностей браузера
В ASP.NET версии 3.5 с пакетом обновления 1 (SP1) можно определить возможности браузера следующими способами:
На уровне компьютера создается или обновляется
.browserXML-файл в следующей папке:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\BrowsersПосле определения возможности браузера выполните следующую команду из командной строки Visual Studio, чтобы перестроить сборку возможностей браузера и добавить ее в GAC:
aspnet_regbrowsers.exe -I cДля отдельного приложения вы создаете
.browserфайл в папке приложенияApp_Browsers.
Эти подходы требуют изменения XML-файлов, а для изменений на уровне компьютера необходимо перезапустить приложение после запуска процесса aspnet_regbrowsers.exe.
ASP.NET 4 включает функцию, называемую поставщиками возможностей браузера. Как следует из названия, это позволяет создать поставщика, который, в свою очередь, позволяет использовать собственный код для определения возможностей браузера.
На практике разработчики часто не определяют пользовательские возможности браузера. Файлы браузера трудно обновить, процесс их обновления довольно сложный, а синтаксис XML для .browser файлов может быть сложным для использования и определения. Что значительно упростило бы этот процесс, так это если бы существовал общий синтаксис определения браузера, база данных, содержащая актуальные определения браузеров, или даже веб-служба для такой базы данных. Новая функция поставщиков возможностей браузера делает эти сценарии возможными и практичными для сторонних разработчиков.
Существует два main подхода к использованию новой функции поставщика возможностей браузера ASP.NET 4: расширение функции определения возможностей браузера ASP.NET или полная замена ее. В следующих разделах сначала описывается, как заменить функциональные возможности, а затем расширить ее.
Замена функциональных возможностей браузера ASP.NET
Чтобы полностью заменить функции определения возможностей браузера ASP.NET, выполните следующие действия.
Создайте класс поставщика, производный от HttpCapabilitiesProvider и переопределяющий метод GetBrowserCapabilities , как показано в следующем примере:
public class CustomProvider : HttpCapabilitiesProvider { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); values[String.Empty] = request.UserAgent; values["browser"] = "MyCustomBrowser"; browserCaps.Capabilities = values; return browserCaps; } }Код в этом примере создает новый объект HttpBrowserCapabilities , указав только возможность с именем browser и задав для нее значение MyCustomBrowser.
Зарегистрируйте поставщик в приложении.
Чтобы использовать поставщик с приложением, необходимо добавить атрибут provider в раздел browserCaps в файлах
Web.configилиMachine.config. (Вы также можете определить атрибуты поставщика в элементе location для определенных каталогов в приложении, например в папке для определенного мобильного устройства.) В следующем примере показано, как задать атрибут поставщика в файле конфигурации:<system.web> <browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, Version=1.0.0.0, Culture=neutral" /> </system.web>Еще один способ зарегистрировать новое определение возможностей браузера — использовать код, как показано в следующем примере:
void Application_Start(object sender, EventArgs e) { HttpCapabilitiesBase.BrowserCapabilitiesProvider = new ClassLibrary2.CustomProvider(); // ... }Этот код должен выполняться в событии
Global.asaxApplication_Start файла. Любое изменение класса BrowserCapabilitiesProvider должно произойти до выполнения любого кода в приложении, чтобы убедиться, что кэш остается в допустимом состоянии для разрешенного объекта HttpCapabilitiesBase .
Кэширование объекта HttpBrowserCapabilities
В предыдущем примере есть одна проблема, которая заключается в том, что код будет выполняться каждый раз при вызове настраиваемого поставщика для получения объекта HttpBrowserCapabilities . Это может произойти несколько раз во время каждого запроса. В этом примере код для поставщика не выполняет никаких действий. Однако если код в пользовательском поставщике выполняет значительную работу для получения объекта HttpBrowserCapabilities , это может повлиять на производительность. Чтобы предотвратить это, можно кэшировать объект HttpBrowserCapabilities . Выполните следующие действия.
Создайте класс, производный от HttpCapabilitiesProvider, как в следующем примере:
public class CustomProvider : HttpCapabilitiesProvider { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { string cacheKey = BuildCacheKey(); int cacheTime = GetCacheTime(); HttpBrowserCapabilities browserCaps = HttpContext.Current.Cache[cacheKey] as HttpBrowserCapabilities; if (browserCaps == null) { HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); values[String.Empty] = request.UserAgent; values["browser"] = "MyCustomBrowser"; browserCaps.Capabilities = values; HttpContext.Current.Cache.Insert(cacheKey, browserCaps, null, DateTime.MaxValue, TimeSpan.FromSeconds(cacheTime)); } return browserCaps; } }В этом примере код создает ключ кэша путем вызова пользовательского метода BuildCacheKey и получает продолжительность кэширования путем вызова пользовательского метода GetCacheTime. Затем код добавляет разрешенный объект HttpBrowserCapabilities в кэш. Объект можно извлечь из кэша и повторно использовать в последующих запросах, использующих настраиваемый поставщик.
Зарегистрируйте поставщик в приложении, как описано в предыдущей процедуре.
Расширение возможностей браузера ASP.NET
В предыдущем разделе описано, как создать объект HttpBrowserCapabilities в ASP.NET 4. Вы также можете расширить возможности браузера ASP.NET, добавив новые определения возможностей браузера к тем, которые уже находятся в ASP.NET. Это можно сделать без использования определений браузера XML. В следующей процедуре показано, как.
Создайте класс, производный от HttpCapabilitiesEvaluator и переопределяющий метод GetBrowserCapabilities , как показано в следующем примере:
public class CustomProvider : HttpCapabilitiesEvaluator { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request); if (browserCaps.Browser == "Unknown") { browserCaps = MyBrowserCapabilitiesEvaulator(request); } return browserCaps; } }Этот код сначала использует функции ASP.NET браузера для идентификации браузера. Однако если браузер не идентифицируется на основе сведений, определенных в запросе (то есть, если свойство Browser объекта HttpBrowserCapabilities является строкой Unknown), код вызывает настраиваемый поставщик (MyBrowserCapabilitiesEvaluator) для идентификации браузера.
Зарегистрируйте поставщик в приложении, как описано в предыдущем примере.
Расширение функциональных возможностей браузера путем добавления новых возможностей в определения существующих возможностей
Помимо создания настраиваемого поставщика определений браузера и динамического создания новых определений браузера, вы можете расширить существующие определения браузеров с помощью дополнительных возможностей. Это позволяет использовать определение, близкое к нужному, но не имеет лишь нескольких возможностей. Для этого выполните следующие действия.
Создайте класс, производный от HttpCapabilitiesEvaluator и переопределяющий метод GetBrowserCapabilities , как показано в следующем примере:
public class CustomProvider : HttpCapabilitiesEvaluator { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request); if (browserCaps.Browser == "Unknown") { browserCaps = MyBrowserCapabilitiesEvaulator(request); } return browserCaps; } }Пример кода расширяет существующий ASP.NET класса HttpCapabilitiesEvaluator и получает объект HttpBrowserCapabilities , соответствующий текущему определению запроса, с помощью следующего кода:
HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request);Затем код может добавить или изменить возможность для этого браузера. Указать новые возможности браузера можно двумя способами:
Добавьте пару "ключ-значение" в объект IDictionary , предоставляемый свойством Capabilities объекта HttpCapabilitiesBase . В предыдущем примере код добавляет возможность с именем MultiTouch со значением true.
Задайте существующие свойства объекта HttpCapabilitiesBase . В предыдущем примере код задает для свойства Framesзначение true. Это свойство является просто методом доступа для объекта IDictionary , который предоставляется свойством Capabilities .
Примечание
Примечание. Эта модель применяется к любому свойству HttpBrowserCapabilities, включая адаптеры управления.
Зарегистрируйте поставщик в приложении, как описано в предыдущей процедуре.
Маршрутизация в ASP.NET 4
ASP.NET 4 добавлена встроенная поддержка использования маршрутизации с веб-формы. Маршрутизация позволяет настроить приложение для приема URL-адресов запросов, которые не соответствуют физическим файлам. Вместо этого можно использовать маршрутизацию для определения URL-адресов, значимых для пользователей и помогающих в оптимизации поисковой системы (SEO) для вашего приложения. Например, URL-адрес страницы, на котором отображаются категории продуктов в существующем приложении, может выглядеть следующим образом:
http://website/products.aspx?categoryid=12
С помощью маршрутизации можно настроить приложение на прием следующего URL-адреса для отображения той же информации:
http://website/products/software
Маршрутизация доступна начиная с ASP.NET 3.5 с пакетом обновления 1 (SP1). (Пример использования маршрутизации в ASP.NET 3.5 с пакетом обновления 1 (SP1) см. в записи Использование маршрутизации с webForms в блоге Фила Хаака.) Однако ASP.NET 4 включает некоторые функции, упрощающие использование маршрутизации, в том числе следующие:
- Класс PageRouteHandler , который представляет собой простой обработчик HTTP, который используется при определении маршрутов. Класс передает данные на страницу, на которую направляется запрос.
- Новые свойства HttpRequest.RequestContext и Page.RouteData (который является прокси-сервером для объекта HttpRequest.RequestContext.RouteData ). Эти свойства упрощают доступ к информации, передаваемой из маршрута.
- Следующие новые построители выражений, определенные в System.Web.Compilation.RouteUrlExpressionBuilder и System.Web.Compilation.RouteValueExpressionBuilder:
- RouteUrl, предоставляющий простой способ создания URL-адреса, соответствующего URL-адресу маршрута в серверном элементе управления ASP.NET.
- RouteValue, предоставляющий простой способ извлечения сведений из объекта RouteContext .
- Класс RouteParameter , который упрощает передачу данных, содержащихся в объекте RouteContext , в запрос к элементу управления источником данных (аналогично FormParameter).
Маршрутизация для страниц веб-формы
В следующем примере показано, как определить маршрут веб-формы с помощью нового метода MapPageRoute класса Route:
public class Global : System.Web.HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
RouteTable.Routes.MapPageRoute("SearchRoute",
"search/{searchterm}", "~/search.aspx");
RouteTable.Routes.MapPageRoute("UserRoute",
"users/{username}", "~/users.aspx");
}
}
ASP.NET 4 представлен метод MapPageRoute . Следующий пример эквивалентен определению SearchRoute, приведенному в предыдущем примере, но использует класс PageRouteHandler .
RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}",
new PageRouteHandler("~/search.aspx")));
Код в примере сопоставляет маршрут с физической страницей (в первом маршруте — с ~/search.aspx). Первое определение маршрута также указывает, что параметр с именем searchterm должен быть извлечен из URL-адреса и передан на страницу.
Метод MapPageRoute поддерживает следующие перегрузки методов:
- MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess)
- MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults)
- MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults, RouteValueDictionary constraint constraints)
Параметр checkPhysicalUrlAccess указывает, должен ли маршрут проверка разрешения безопасности для физической страницы, на которой выполняется маршрутизация (в данном случае search.aspx) и разрешения на входящий URL-адрес (в данном случае search/{searchterm}). Если значение checkPhysicalUrlAccess равно false, будут проверяться только разрешения для входящего URL-адреса. Эти разрешения определяются в Web.config файле с помощью следующих параметров:
<configuration>
<location path="search.aspx">
<system.web>
<authorization>
<allow roles="admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
<location path="search">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration>
В примере конфигурации доступ к физической странице search.aspx запрещен для всех пользователей, кроме тех, кто имеет роль администратора. Если для параметра checkPhysicalUrlAccess задано значение true (значение по умолчанию), доступ к URL-адресу /search/{searchterm} имеют только пользователи-администраторы, так как физическая страница search.aspx ограничена пользователями с этой ролью. Если параметр checkPhysicalUrlAccess имеет значение false и сайт настроен, как показано в предыдущем примере, всем пользователям, прошедшим проверку подлинности, разрешен доступ к URL-адресу /search/{searchterm}.
Чтение сведений о маршрутизации на странице веб-формы
В коде физической страницы веб-формы можно получить доступ к сведениям, извлеченным маршрутизацией из URL-адреса (или другим сведениям, добавленным другим объектом в объект RouteData), используя два новых свойства: HttpRequest.RequestContext и Page.RouteData. (Page.RouteData заключает в оболочку HttpRequest.RequestContext.RouteData.) В следующем примере показано, как использовать Page.RouteData.
protected void Page_Load(object sender, EventArgs e)
{
string searchterm = Page.RouteData.Values["searchterm"] as string;
label1.Text = searchterm;
}
Код извлекает значение, переданное для параметра searchterm, как определено в примере маршрута ранее. Рассмотрим следующий URL-адрес запроса:
http://localhost/search/scott/
При выполнении этого запроса на странице будет отображаться search.aspx слово scott.
Доступ к сведениям о маршрутизации в разметке
Метод, описанный в предыдущем разделе, показывает, как получить данные маршрута в коде на странице веб-формы. В разметке также можно использовать выражения, которые предоставляют доступ к той же информации. Построитель выражений — это мощный и элегантный способ работы с декларативным кодом. (Дополнительные сведения см. в записи Express Yourself With Custom Expression Builders в блоге Фила Хаака.)
ASP.NET 4 включает два новых построителя выражений для маршрутизации веб-формы. В следующем примере показано, как их использовать.
<asp:HyperLink ID="HyperLink1" runat="server"
NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>
В этом примере выражение RouteUrl используется для определения URL-адреса, основанного на параметре маршрута. Это избавляет вас от необходимости жесткого написания полного URL-адреса в разметке и позволяет изменить структуру URL-адресов позже, не требуя каких-либо изменений в этой ссылке.
В зависимости от маршрута, определенного ранее, эта разметка создает следующий URL-адрес:
http://localhost/search/scott
ASP.NET автоматически определяет правильный маршрут (то есть формирует правильный URL-адрес) на основе входных параметров. Вы также можете включить в выражение имя маршрута, которое позволяет указать маршрут для использования.
В следующем примере показано, как использовать выражение RouteValue .
<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />
При запуске страницы, содержащей этот элемент управления, в метке отображается значение scott.
Выражение RouteValue упрощает использование данных маршрута в разметке и позволяет избежать необходимости работать с более сложным синтаксисом Page.RouteData["x"] в разметке.
Использование данных маршрута для параметров управления источником данных
Класс RouteParameter позволяет указать данные маршрута в качестве значения параметра для запросов в элементе управления источником данных. Он работает так же, как класс , как показано в следующем примере:
<asp:sqldatasource id="SqlDataSource1" runat="server"
connectionstring="<%$ ConnectionStrings:MyNorthwind %>"
selectcommand="SELECT CompanyName,ShipperID FROM Shippers where
CompanyName=@companyname"
<selectparameters>
<asp:routeparameter name="companyname" RouteKey="searchterm" />
</selectparameters>
</asp:sqldatasource>
В этом случае значение параметра маршрута searchterm будет использоваться для @companyname параметра в инструкции Select .
Настройка идентификаторов клиентов
Новое свойство ClientIDMode устраняет давнюю проблему в ASP.NET, а именно то, как элементы управления создают атрибут id для элементов, которые они отрисовывают. Знание атрибута id для отрисованных элементов важно, если приложение содержит клиентский скрипт, который ссылается на эти элементы.
Атрибут id в HTML, который отображается для серверных веб-элементов управления, создается на основе свойства ClientID элемента управления . До ASP.NET 4 алгоритм создания атрибута id из свойства ClientID состоит в том, чтобы сцепить контейнер именования (если таковой имеется) с идентификатором, а в случае повторяющихся элементов управления (как в элементах управления данными) добавить префикс и последовательный номер. Хотя это всегда гарантирует, что идентификаторы элементов управления на странице являются уникальными, алгоритм приводит к тому, что идентификаторы элементов управления не были предсказуемыми и поэтому трудно ссылаться в клиентском скрипте.
Новое свойство ClientIDMode позволяет более точно указать, как создается идентификатор клиента для элементов управления. Свойство ClientIDMode можно задать для любого элемента управления, в том числе для страницы. Возможные параметры:
- AutoID — это эквивалент алгоритму для создания значений свойств ClientID , который использовался в более ранних версиях ASP.NET.
- Static — указывает, что значение ClientID будет совпадать с идентификатором без объединения идентификаторов родительских контейнеров именования. Это может быть полезно в пользовательских веб-элементах управления. Поскольку пользовательский веб-элемент управления может находиться на разных страницах и в разных элементах управления контейнера, может быть сложно написать клиентский скрипт для элементов управления, использующих алгоритм AutoID , так как невозможно предсказать, какие значения идентификаторов будут.
- Прогнозируемый — этот параметр в основном предназначен для элементов управления данными, использующих повторяющиеся шаблоны. Он объединяет свойства идентификатора контейнеров именования элемента управления, но созданные значения ClientID не содержат таких строк, как "ctlxxxx". Этот параметр работает в сочетании со свойством ClientIDRowSuffix элемента управления . Для свойства ClientIDRowSuffix задается имя поля данных, а значение этого поля используется в качестве суффикса для созданного значения ClientID . Обычно в качестве значения ClientIDRowSuffix используется первичный ключ записи данных.
- Наследовать — этот параметр является поведением по умолчанию для элементов управления; он указывает, что идентификатор элемента управления совпадает с родительским.
Свойство ClientIDMode можно задать на уровне страницы. Определяет значение ClientIDMode по умолчанию для всех элементов управления на текущей странице.
Значение ClientIDMode по умолчанию на уровне страницы — AutoID, а значение ClientIDMode по умолчанию на уровне элемента управления — Inherit. В результате, если это свойство не задано ни в одном месте кода, все элементы управления будут по умолчанию использовать алгоритм AutoID .
Значение уровня страницы задается в директиве @ Page , как показано в следующем примере:
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
ClientIDMode="Predictable" %>
Вы также можете задать значение ClientIDMode в файле конфигурации на уровне компьютера (компьютера) или на уровне приложения. Определяет параметр ClientIDMode по умолчанию для всех элементов управления на всех страницах приложения. Если задать значение на уровне компьютера, он определяет параметр ClientIDMode по умолчанию для всех веб-сайтов на этом компьютере. В следующем примере показан параметр ClientIDMode в файле конфигурации:
<system.web>
<pages clientIDMode="Predictable"></pages>
</system.web>
Как отмечалось ранее, значение свойства ClientID является производным от контейнера именования родительского элемента управления. В некоторых сценариях, например при использовании master страниц, элементы управления могут в конечном итоге получить идентификаторы, подобные идентификаторам в следующем отрисованном HTML-коде:
<div id="ctl00_ContentPlaceHolder1_ParentPanel">
<div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1">
<input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1"
type="text" value="Hello!"
id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" />
</div>
Несмотря на то, что входной элемент, отображаемый в разметке (из элемента управления TextBox), содержит только два контейнера именования на странице (вложенные элементы управления ContentPlaceholder), из-за способа обработки master страниц конечным результатом является идентификатор элемента управления, подобный следующему:
ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1
Этот идентификатор гарантированно уникален на странице, но неоправданно длинный для большинства целей. Представьте, что вы хотите уменьшить длину отображаемого идентификатора и получить больше контроля над тем, как создается идентификатор. (Например, необходимо исключить префиксы ctlxxx.) Самый простой способ добиться этого — задать свойство ClientIDMode , как показано в следующем примере:
<tc:NamingPanel runat="server" ID="ParentPanel" ClientIDMode="Static">
<tc:NamingPanel runat="server" ID="NamingPanel1" ClientIDMode="Predictable">
<asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox>
</tc:NamingPanel>
</tc:NamingPanel>
В этом примере свойству ClientIDMode присваивается значение Static для самого внешнего элемента NamingPanel, а для внутреннего элемента NamingControl — значение Predictable. Эти параметры приводят к следующей разметке (предполагается, что остальная часть страницы и master страница будут такими же, как в предыдущем примере):
<div id="ParentPanel">
<div id="ParentPanel_NamingPanel1">
<input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1"
type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" />
</div>
Параметр Static позволяет сбросить иерархию именования для всех элементов управления в самом внешнем элементе NamingPanel и исключить идентификаторы ContentPlaceHolder и MasterPage из созданного идентификатора. (Атрибут имени отрисованных элементов не затрагивается, поэтому обычные функции ASP.NET сохраняются для событий, состояния представления и т. д.) Побочным эффектом сброса иерархии именования является то, что даже при перемещении разметки элементов NamingPanel в другой элемент управления ContentPlaceholder идентификаторы отрисованных клиентов остаются неизменными.
Примечание
Примечание. Убедитесь, что отображаемые идентификаторы элементов управления являются уникальными. Если это не так, это может нарушить любую функциональность, для которой требуются уникальные идентификаторы для отдельных элементов HTML, таких как функция client document.getElementById .
Создание прогнозируемых идентификаторов клиентов в элементах управления Data-Bound
Значения ClientID , создаваемые для элементов управления в элементе управления списком с привязкой к данным устаревшим алгоритмом, могут быть длинными и на самом деле непредсказуемыми. Функция ClientIDMode может помочь вам получить больший контроль над тем, как создаются эти идентификаторы.
Разметка в следующем примере включает элемент управления ListView :
<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1"
OnSelectedIndexChanged="ListView1_SelectedIndexChanged"
ClientIDMode="Predictable"
RowClientIDRowSuffix="ProductID">
</asp:ListView>
В предыдущем примере свойства ClientIDMode и RowClientIDRowSuffix задаются в разметке. Свойство ClientIDRowSuffix можно использовать только в элементах управления с привязкой к данным, и его поведение зависит от того, какой элемент управления вы используете. Отличия следующие:
Элемент управления GridView — можно указать имя одного или нескольких столбцов в источнике данных, которые объединяются во время выполнения для создания идентификаторов клиентов. Например, если задать для RowClientIDRowSuffix значение "ProductName, ProductId", идентификаторы элементов управления для отрисованных элементов будут иметь следующий формат:
rootPanel_GridView1_ProductNameLabel_Chai_1Элемент управления ListView — можно указать один столбец в источнике данных, который добавляется к идентификатору клиента. Например, если для параметра ClientIDRowSuffix задано значение ProductName, отображаемые идентификаторы элементов управления будут иметь следующий формат:
rootPanel_ListView1_ProductNameLabel_1В этом случае значение 1 является производным от идентификатора продукта текущего элемента данных.
Элемент управления Repeater — этот элемент управления не поддерживает свойство ClientIDRowSuffix . В элементе управления Repeater используется индекс текущей строки. При использовании ClientIDMode="Predictable" с элементом управления Repeater создаются идентификаторы клиентов в следующем формате:
Repeater1_ProductNameLabel_0Конечный 0 — это индекс текущей строки.
Элементы управления FormView и DetailsView не отображают несколько строк, поэтому они не поддерживают свойство ClientIDRowSuffix .
Сохранение выделения строк в элементах управления данными
Элементы управления GridView и ListView позволяют пользователям выбирать строку. В предыдущих версиях ASP.NET выбор был основан на индексе строки на странице. Например, если выбрать третий элемент на странице 1, а затем перейти на страницу 2, будет выбран третий элемент на этой странице.
Сохраняемый выбор изначально поддерживался только в проектах динамических данных в платформа .NET Framework 3.5 с пакетом обновления 1 (SP1). Если эта функция включена, текущий выбранный элемент основан на ключе данных для элемента. Это означает, что при выборе третьей строки на странице 1 и переходе на страницу 2 ничего не будет выбрано на странице 2. При переходе на страницу 1 третья строка по-прежнему выбирается. Сохраненный выбор теперь поддерживается для элементов управления GridView и ListView во всех проектах с помощью свойства EnablePersistedSelection , как показано в следующем примере:
<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true">
</asp:GridView>
Элемент управления "Диаграмма ASP.NET"
Элемент управления диаграмма ASP.NET расширяет возможности визуализации данных в платформа .NET Framework. С помощью элемента управления Диаграмма можно создавать ASP.NET страницы с интуитивно понятными и наглядными диаграммами для сложного статистического или финансового анализа. Элемент управления ASP.NET Chart был представлен в качестве надстройки для выпуска платформа .NET Framework версии 3.5 с пакетом обновления 1 (SP1) и является частью выпуска платформа .NET Framework 4.
Элемент управления включает следующие функции:
- 35 различных типов диаграмм.
- Неограниченное количество областей диаграммы, заголовков, условных обозначений и заметок.
- Широкий выбор параметров внешнего вида для всех элементов диаграммы.
- Трехмерная поддержка для большинства типов диаграмм.
- Смарт-метки данных, которые могут автоматически помещаться вокруг точек данных.
- Чередующиеся линии, разрывы масштабирования и логарифмическое масштабирование.
- Более 50 финансовых и статистических формул для анализа данных и преобразования данных.
- Простая привязка и обработка данных диаграммы.
- Поддержка распространенных форматов данных, таких как даты, время и валюта.
- Поддержка интерактивности и настройки на основе событий, включая события нажатия клиента с помощью Ajax.
- Управление состоянием.
- Двоичные потоки.
На следующих рисунках показаны примеры финансовых диаграмм, созданных элементом управления "Диаграмма ASP.NET".
Рис. 2. Примеры элементов управления "Диаграмма ASP.NET"
Дополнительные примеры использования элемента управления "Диаграмма ASP.NET", скачайте пример кода на странице Примеры среды для элементов управления диаграммами (Майкрософт ) на веб-сайте MSDN. Дополнительные примеры содержимого сообщества можно найти на форуме по управлению диаграммами.
Добавление элемента управления "Диаграмма" на страницу ASP.NET
В следующем примере показано, как добавить элемент управления Диаграмма на страницу ASP.NET с помощью разметки. В этом примере элемент управления Диаграмма создает гистограмму для статических точек данных.
<asp:Chart ID="Chart1" runat="server">
<Series>
<asp:Series Name="Series1" ChartType="Column">
<Points>
<asp:DataPoint AxisLabel="Product A" YValues="345"/>
<asp:DataPoint AxisLabel="Product B" YValues="456"/>
<asp:DataPoint AxisLabel="Product C" YValues="125"/>
<asp:DataPoint AxisLabel="Product D" YValues="957"/> &
lt;/Points>
</asp:Series>
</Series>
<ChartAreas>
<asp:ChartArea Name="ChartArea1">
<AxisY IsLogarithmic="True" />
</asp:ChartArea>
</ChartAreas>
<Legends>
<asp:Legend Name="Legend1" Title="Product Sales" />
</Legends>
</asp:Chart>
Использование трехмерных диаграмм
Элемент управления Диаграмма содержит коллекцию ChartAreas , которая может содержать объекты ChartArea , определяющие характеристики областей диаграммы. Например, чтобы использовать трехмерную диаграмму для области диаграммы, используйте свойство Area3DStyle , как показано в следующем примере:
<asp:ChartArea Name="ChartArea1">
<area3dstyle
Rotation="10"
Perspective="10"
Enable3D="True"
Inclination="15"
IsRightAngleAxes="False"
WallWidth="0"
IsClustered="False" />
<%-- Additional markup here --%>
</asp:ChartArea>
На рисунке ниже показана объемная диаграмма с четырьмя рядами линейчатой диаграммы.
Рис. 3. Объемная линейчатая диаграмма
Использование разрывов масштабирования и логарифмических шкал
Разрывы масштабирования и логарифмические шкалы — это два дополнительных способа добавления утонченности в диаграмму. Эти функции зависят от каждой оси в области диаграммы. Например, чтобы использовать эти функции на основной оси Y области диаграммы, используйте свойства AxisY.IsLogarithmic и ScaleBreakStyle в объекте ChartArea . В следующем фрагменте кода показано, как использовать разрывы масштабирования на основной оси Y.
<asp:ChartArea Name="ChartArea1">
<axisy>
<ScaleBreakStyle
BreakLineStyle="Wave"
CollapsibleSpaceThreshold="40"
Enabled="True" />
</axisy>
<%-- Additional markup here --%>
</asp:ChartArea>
На рисунке ниже показана ось Y с включенными разрывами масштаба.
Рис. 4. Разрывы масштабирования
Фильтрация данных с помощью элемента управления QueryExtender
Очень распространенной задачей для разработчиков, создающих веб-страницы на основе данных, является фильтрация данных. Обычно это выполняется путем создания предложений Where в элементах управления источником данных. Этот подход может быть сложным, и в некоторых случаях синтаксис Where не позволяет воспользоваться всеми функциональными возможностями базовой базы данных.
Чтобы упростить фильтрацию, в ASP.NET 4 добавлен новый элемент управления QueryExtender . Этот элемент управления можно добавить в элементы управления EntityDataSource или LinqDataSource , чтобы отфильтровать данные, возвращаемые этими элементами управления. Так как элемент управления QueryExtender использует LINQ, фильтр применяется к серверу базы данных перед отправкой данных на страницу, что приводит к очень эффективным операциям.
Элемент управления QueryExtender поддерживает различные параметры фильтра. В следующих разделах описаны эти параметры и приведены примеры их использования.
Поиск
Для параметра поиска элемент управления QueryExtender выполняет поиск в указанных полях. В следующем примере элемент управления использует текст, введенный в элементе управления TextBoxSearch, и ищет его содержимое в ProductName столбцах и Supplier.CompanyName в данных, возвращаемых из элемента управления LinqDataSource .
<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:SearchExpression DataFields="ProductName, Supplier.CompanyName"
SearchType="StartsWith">
<asp:ControlParameter ControlID="TextBoxSearch" />
</asp:SearchExpression>
</asp:QueryExtender>
Диапазон
Параметр range аналогичен параметру поиска, но указывает пару значений для определения диапазона. В следующем примере элемент управления QueryExtender выполняет поиск столбца UnitPrice в данных, возвращенных из элемента управления LinqDataSource . Диапазон считывается из элементов управления TextBoxFrom и TextBoxTo на странице.
<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:RangeExpression DataField="UnitPrice" MinType="Inclusive"
MaxType="Inclusive">
<asp:ControlParameter ControlID="TextBoxFrom" />
<asp:ControlParameter ControlID="TexBoxTo" />
</asp:RangeExpression>
</asp:QueryExtender>
PropertyExpression
Параметр выражения свойства позволяет определить сравнение со значением свойства. Если выражение имеет значение true, возвращаются проверяемые данные. В следующем примере элемент управления QueryExtender фильтрует данные, сравнивая данные в Discontinued столбце со значением элемента управления CheckBoxDiscontinued на странице.
<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:PropertyExpression>
<asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />
</asp:PropertyExpression>
</asp:QueryExtender>
CustomExpression
Наконец, можно указать пользовательское выражение для использования с элементом управления QueryExtender . Этот параметр позволяет вызывать функцию на странице, которая определяет логику настраиваемого фильтра. В следующем примере показано, как декларативно указать пользовательское выражение в элементе управления QueryExtender .
<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:CustomExpression OnQuerying="FilterProducts" />
</asp:QueryExtender>
В следующем примере показана пользовательская функция, вызываемая элементом управления QueryExtender . В этом случае вместо запроса базы данных, включающего предложение Where , код использует запрос LINQ для фильтрации данных.
protected void FilterProducts(object sender, CustomExpressionEventArgs e)
{
e.Query = from p in e.Query.Cast()
where p.UnitPrice >= 10
select p;
}
В этих примерах показано, что в элементе управления QueryExtender одновременно используется только одно выражение. Однако в элемент управления QueryExtender можно включить несколько выражений.
Выражения кода в html-коде
Некоторые ASP.NET сайты (особенно с ASP.NET MVC) в значительной степени полагаются на использование <%= expression %> синтаксиса (часто называемого "самородками кода") для записи текста в ответ. При использовании выражений кода легко забыть закодировать текст в формате HTML. Если текст поступает из введенных пользователем данных, он может оставить страницы открытыми для атак XSS (межсайтовых сценариев).
В ASP.NET 4 представлен следующий новый синтаксис для выражений кода:
<%: expression %>
Этот синтаксис использует кодировку HTML по умолчанию при записи в ответ. Это новое выражение эффективно преобразуется в следующее:
<%= HttpUtility.HtmlEncode(expression) %>
Например, <%: Request["UserInput"] %> выполняет кодирование HTML со значением Request["UserInput"].
Цель этой функции заключается в том, чтобы можно было заменить все экземпляры старого синтаксиса новым, чтобы вы не были вынуждены решать на каждом шаге, какой из них использовать. Однако бывают случаи, когда выводимый текст должен быть HTML или уже закодирован, в этом случае это может привести к двойному кодированию.
В этих случаях в ASP.NET 4 представлен новый интерфейс IHtmlString, а также конкретная реализация HtmlString. Экземпляры этих типов позволяют указать, что возвращаемое значение уже правильно закодировано (или иным образом проверено) для отображения в формате HTML и поэтому значение не должно быть закодировано в ФОРМАТЕ HTML. Например, следующее не должно быть (и не должно быть) закодировано в ФОРМАТЕ HTML:
<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>
ASP.NET вспомогательные методы MVC 2 были обновлены для работы с этим новым синтаксисом, чтобы они не были закодированы двойным образом, а только при выполнении ASP.NET 4. Этот новый синтаксис не работает при запуске приложения с помощью ASP.NET 3.5 с пакетом обновления 1 (SP1).
Помните, что это не гарантирует защиту от атак XSS. Например, HTML- код, использующий значения атрибутов, которые не находятся в кавычках, может содержать пользовательский ввод, который по-прежнему уязвим. Обратите внимание, что выходные данные элементов управления ASP.NET и вспомогательных ASP.NET MVC всегда включают значения атрибутов в кавычки, что является рекомендуемым подходом.
Аналогичным образом, этот синтаксис не выполняет кодирование JavaScript, например при создании строки JavaScript на основе введенных пользователем данных.
Изменения шаблона проекта
В более ранних версиях ASP.NET при использовании Visual Studio для создания проекта веб-сайта или проекта веб-приложения результирующие проекты содержат только страницу Default.aspx, файл по умолчанию Web.config и App_Data папку, как показано на следующем рисунке:
Visual Studio также поддерживает тип проекта Пустой веб-сайт, который вообще не содержит файлов, как показано на следующем рисунке:
В результате для начинающих существует очень мало рекомендаций по созданию рабочего веб-приложения. Таким образом, в ASP.NET 4 представлены три новых шаблона: один для пустого проекта веб-приложения и по одному для проекта веб-приложения и веб-сайта.
Пустой шаблон веб-приложения
Как следует из названия, шаблон Пустое веб-приложение является проектом веб-приложения с урезанным. Этот шаблон проекта можно выбрать в диалоговом окне Новый проект Visual Studio, как показано на следующем рисунке:
(Щелкните для просмотра полноразмерного изображения)
При создании пустого веб-приложения ASP.NET Visual Studio создает следующий макет папки:
Это похоже на макет пустого веб-сайта из более ранних версий ASP.NET, за одним исключением. В Visual Studio 2010 проекты пустого веб-приложения и пустого веб-сайта содержат следующий минимальный Web.config файл, содержащий сведения, используемые Visual Studio для определения платформы, на которую предназначен проект:
Без этого свойства targetFramework Visual Studio по умолчанию нацеливается на платформа .NET Framework 2.0, чтобы сохранить совместимость при открытии старых приложений.
Шаблоны проектов веб-приложений и веб-сайтов
Два других новых шаблона проектов, поставляемые с Visual Studio 2010, содержат существенные изменения. На следующем рисунке показан макет проекта, который создается при создании нового проекта веб-приложения. (Макет для проекта веб-сайта практически идентичен.)
Проект включает несколько файлов, которые не были созданы в более ранних версиях. Кроме того, в новом проекте веб-приложения настроены базовые функции членства, что позволяет быстро приступить к защите доступа к новому приложению. Из-за этого включения Web.config файл для нового проекта содержит записи, которые используются для настройки членства, ролей и профилей. В следующем примере показан Web.config файл для нового проекта веб-приложения. (В этом случае roleManager отключен.)
(Щелкните для просмотра полноразмерного изображения)
Проект также содержит второй Web.config файл в каталоге Account . Второй файл конфигурации предоставляет способ защиты доступа к странице ChangePassword.aspx для пользователей без входа. В следующем примере показано содержимое второго Web.config файла.
Страницы, созданные по умолчанию в новых шаблонах проектов, также содержат больше содержимого, чем в предыдущих версиях. Проект содержит страницу master по умолчанию и ФАЙЛ CSS, а страница по умолчанию (Default.aspx) настроена для использования страницы master по умолчанию. В результате при первом запуске веб-приложения или веб-сайта страница по умолчанию (домашняя) уже работает. На самом деле это похоже на страницу по умолчанию, отображается при запуске нового приложения MVC.
(Щелкните для просмотра полноразмерного изображения)
Цель этих изменений в шаблонах проектов — предоставить рекомендации по созданию нового веб-приложения. Семантически правильная, строгая разметка, совместимая с XHTML 1.0, и макет, заданный с помощью CSS, страницы в шаблонах представляют рекомендации по созданию веб-приложений ASP.NET 4. Страницы по умолчанию также имеют макет с двумя столбцами, который можно легко настроить.
Например, представьте, что для нового веб-приложения вы хотите изменить некоторые цвета и вставить логотип компании вместо логотипа My ASP.NET Application. Для этого создайте каталог в для Content хранения образа логотипа:
Чтобы добавить изображение на страницу, откройте Site.Master файл, найдите, где определен текст My ASP.NET Application, и замените его элементом image , атрибуту src которого присвоено новое изображение логотипа, как показано в следующем примере:
(Щелкните для просмотра полноразмерного изображения)
Затем можно перейти в файл Site.css и изменить определения классов CSS, чтобы изменить цвет фона страницы, а также цвет заголовка.
В результате этих изменений можно отобразить настраиваемую домашнюю страницу без особых усилий:
(Щелкните для просмотра полноразмерного изображения)
Улучшения CSS
Одной из основных областей работы в ASP.NET 4 является помощь в подготовке к просмотру HTML в соответствии с последними стандартами HTML. Сюда входят изменения в том, как ASP.NET серверных веб-элементах управления используют стили CSS.
Параметр совместимости для отрисовки
По умолчанию, когда веб-приложение или веб-сайт нацелены на платформа .NET Framework 4, атрибут controlRenderingCompatibilityVersion элемента pages имеет значение "4.0". Этот элемент определяется в файле уровня Web.config компьютера и по умолчанию применяется ко всем ASP.NET 4 приложениям:
<system.web>
<pages controlRenderingCompatibilityVersion="3.5|4.0"/>
</system.web>
Значение controlRenderingCompatibility — это строка, которая позволяет использовать новые определения версий в будущих выпусках. В текущем выпуске для этого свойства поддерживаются следующие значения:
- "3.5". Этот параметр указывает на устаревшую отрисовку и разметку. Разметка, отображаемая элементами управления, на 100 % совместима с обратной совместимостью, и параметр свойства xhtmlConformance учитывается.
- "4.0". Если свойство имеет этот параметр, ASP.NET серверные веб-элементы управления выполняют следующие действия.
- Свойство xhtmlConformance всегда обрабатывается как "Strict". В результате элементы управления отображают разметку XHTML 1.0 Strict.
- Отключение элементов управления без ввода больше не отображает недопустимые стили.
- Элементы div вокруг скрытых полей теперь стили, чтобы они не влияли на созданные пользователем правила CSS.
- Элементы управления меню отображают разметку, семантически правильную и соответствующую рекомендациям по специальным возможностям.
- Элементы управления проверкой не отображают встроенные стили.
- Элементы управления, которые ранее отображали border="0" (элементы управления, производные от элемента управления ASP.NET Table и ASP.NET Image ), больше не отображают этот атрибут.
Отключение элементов управления
В ASP.NET 3.5 с пакетом обновления 1 (SP1) и более ранних версиях платформа отрисовывает атрибут disabled в HTML-разметке для любого элемента управления, свойство Которого Enabled имеет значение false. Однако согласно спецификации HTML 4.01 этот атрибут должен иметь только входные элементы.
В ASP.NET 4 можно присвоить свойству controlRenderingCompatibilityVersion значение "3.5", как показано в следующем примере:
<system.web>
<pages controlRenderingCompatibilityVersion="3.5"/>
</system.web>
Вы можете создать разметку для элемента управления Label , как показано ниже, что отключает элемент управления:
<asp:Label id="Label" runat="server" Text="Test" Enabled="false">
Элемент управления Label отрисовывает следующий HTML-код:
<span id="Label1" disabled="disabled">Test</span>
В ASP.NET 4 можно задать для controlRenderingCompatibilityVersion значение "4.0". В этом случае только элементы управления, которые отображают входные элементы, будут отображать отключенный атрибут, если свойство Enabled элемента управления имеет значение false. Элементы управления, которые не отображают входные элементы HTML, вместо этого отрисовывает атрибут класса , который ссылается на класс CSS, который можно использовать для определения отключенного внешнего вида элемента управления. Например, элемент управления Label , показанный в предыдущем примере, создаст следующую разметку:
<span id="Span1" class="aspnetdisabled">Test</span>
Значение по умолчанию для класса, указанного для этого элемента управления, — "aspNetDisabled". Однако это значение по умолчанию можно изменить, задав статическое свойство DisabledCssClass класса WebControl . Для разработчиков элементов управления поведение, используемое для конкретного элемента управления, также можно определить с помощью свойства SupportsDisabledAttribute .
Скрытие элементов div вокруг скрытых полей
ASP.NET 2.0 и более поздних версиях в элементе div отображаются скрытые системные поля (например, скрытый элемент, используемый для хранения сведений о состоянии представления) в элементе div в соответствии со стандартом XHTML. Однако это может вызвать проблему, если правило CSS влияет на элементы div на странице. Например, это может привести к тому, что на странице появится линия в один пиксель вокруг скрытых элементов div . В ASP.NET 4 элементы div , заключающие скрытые поля, созданные ASP.NET добавить ссылку на класс CSS, как показано в следующем примере:
<div class="aspNetHidden">...</div>
Затем можно определить класс CSS, который применяется только к скрытым элементам, созданным ASP.NET, как показано в следующем примере:
<style type="text/css">
DIV# aspNetHidden {border:0;}
</style>
Отрисовка внешней таблицы для шаблонных элементов управления
По умолчанию следующие ASP.NET серверных веб-элементов управления, поддерживающих шаблоны, автоматически упаковываются во внешнюю таблицу, которая используется для применения встроенных стилей:
- Formview
- Имя входа
- PasswordRecovery
- ChangePassword;
- Мастер
- CreateUserWizard
В эти элементы управления добавлено новое свойство RenderOuterTable , которое позволяет удалить внешнюю таблицу из разметки. Например, рассмотрим следующий пример элемента управления FormView :
<asp:FormView ID="FormView1" runat="server">
<ItemTemplate>
Content
</ItemTemplate>
</asp:FormView>
Эта разметка отображает следующие выходные данные на странице, которая включает html-таблицу:
<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;">
<tr>
<td colspan="2">
Content
</td>
</tr>
</table>
Чтобы предотвратить отрисовку таблицы, можно задать свойство RenderOuterTable элемента управления FormView, как показано в следующем примере:
<asp:FormView ID="FormView1" runat="server" RenderOuterTable="false">
В предыдущем примере отображаются следующие выходные данные без элементов table, tr и td :
Содержимое
Это улучшение может упростить стили содержимого элемента управления с помощью CSS, так как элемент управления не отображает непредвиденные теги.
Примечание
Примечание. Это изменение отключает поддержку функции автоформатирования в конструкторе Visual Studio 2010, так как элемент таблицы больше не может содержать атрибуты стиля, созданные параметром автоформата.
Улучшения элемента управления ListView
Элемент управления ListView стал проще использовать в ASP.NET 4. В более ранней версии элемента управления требовалось указать шаблон макета, содержащий серверный элемент управления с известным идентификатором. В следующей разметке показан типичный пример использования элемента управления ListView в ASP.NET 3.5.
<asp:ListView ID="ListView1" runat="server">
<LayoutTemplate>
<asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder>
</LayoutTemplate>
<ItemTemplate>
<% Eval("LastName")%>
</ItemTemplate>
</asp:ListView>
В ASP.NET 4 элементу управления ListView не требуется шаблон макета. Разметку, показанную в предыдущем примере, можно заменить следующей разметкой:
<asp:ListView ID="ListView1" runat="server">
<ItemTemplate>
<% Eval("LastName")%>
</ItemTemplate>
</asp:ListView>
Улучшения элементов управления CheckBoxList и RadioButtonList
В ASP.NET 3.5 можно указать макет для CheckBoxList и RadioButtonList , используя следующие два параметра:
- Поток. Элемент управления отрисовывает элементы span , чтобы они содержали его содержимое.
- Таблица. Элемент управления отображает элемент таблицы , содержащий его содержимое.
В следующем примере показана разметка для каждого из этих элементов управления.
<asp:CheckBoxList ID="CheckBoxList1" runat="server" RepeatLayout="Flow">
<asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>
<asp:RadioButtonList runat="server" RepeatLayout="Table">
<asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>
По умолчанию элементы управления отображают HTML-код следующим образом:
<span id="Span2"><input id="CheckBoxList1_0" type="checkbox"
name="CheckBoxList1$0" /><label for="CheckBoxList1_0">CheckBoxList</label></span>
<table id="RadioButtonList1" border="0">
<tr>
<td><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></td>
</tr>
</table>
Поскольку эти элементы управления содержат списки элементов, для отображения семантически правильного HTML-кода они должны отображать их содержимое с помощью элементов списка HTML (li). Это упрощает для пользователей, которые читают веб-страницы с помощью специальных возможностей, и упрощает стили элементов управления с помощью CSS.
В ASP.NET 4 элементы управления CheckBoxList и RadioButtonList поддерживают следующие новые значения для свойства RepeatLayout :
- OrderedList — содержимое отображается в виде элементов li в элементе ol .
- UnorderedList — содержимое отображается в виде элементов li в элементе ul .
В следующем примере показано, как использовать эти новые значения.
<asp:CheckBoxList ID="CheckBoxList1" runat="server"
RepeatLayout="OrderedList">
<asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>
<asp:RadioButtonList ID="RadioButtonList1" runat="server"
RepeatLayout="UnorderedList">
<asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>
Предыдущая разметка создает следующий КОД HTML:
<ol id="CheckBoxList1">
<li><input id="CheckBoxList1_0" type="checkbox" name="CheckBoxList1$0" value="cbl" /><label for="CheckBoxList1_0">CheckBoxList</label></li>
</ol>
<ul id="RadioButtonList1">
<li><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></li>
</ul>
Примечание
Примечание. Если для параметра RepeatLayoutзадано значение OrderedList или UnorderedList, свойство RepeatDirection больше не может использоваться и будет вызывать исключение во время выполнения, если свойство задано в разметке или коде. Свойство не будет иметь значения, так как визуальный макет этих элементов управления определяется с помощью CSS.
Улучшения элемента управления меню
До ASP.NET 4 элемент управления Меню отображал ряд таблиц HTML. Это усложняло применение стилей CSS за пределами настройки встроенных свойств, а также не соответствовало стандартам специальных возможностей.
В ASP.NET 4 элемент управления теперь отображает HTML с помощью семантической разметки, состоящей из неупорядоченного списка и элементов списка. В следующем примере показана разметка на странице ASP.NET элемента управления Меню .
<asp:Menu ID="Menu1" runat="server">
<Items> <asp:MenuItem Text="Home" Value="Home" />
<asp:MenuItem Text="About" Value="About" />
</Items>
</asp:Menu>
При отрисовки страницы элемент управления создает следующий HTML-код (для ясности код onclick был опущен):
<div id="Menu1">
<ul>
<li><a href="#" onclick="...">Home</a></li>
<li><a href="#" onclick="...">About</a></li>
</ul>
</div>
<script type="text/javascript">
new Sys.WebForms.Menu('Menu1');
</script>
Помимо улучшения отрисовки, навигация по меню с помощью клавиатуры была улучшена с помощью управления фокусом. Когда элемент управления Меню получает фокус, вы можете использовать клавиши со стрелками для навигации по элементам. Элемент управления Меню также теперь присоединяет доступные многофункциональные интернет-приложения (ARIA) роли и атрибуты following theдля улучшения специальных возможностей.
Стили для элемента управления меню отображаются в блоке стилей в верхней части страницы, а не в соответствии с отображаемыми html-элементами. Если вы хотите полностью контролировать стиль элемента управления, можно задать для нового свойства IncludeStyleBlockзначение false, в этом случае блок стиля не создается. Одним из способов использования этого свойства является использование функции автоформата в конструкторе Visual Studio для настройки внешнего вида меню. Затем можно запустить страницу, открыть источник страницы и скопировать отрисованный блок стиля во внешний CSS-файл. В Visual Studio отмените стиль и задайте для IncludeStyleBlockзначение false. В результате внешний вид меню определяется с помощью стилей во внешней таблице стилей.
Мастер и элементы управления CreateUserWizard
Элементы управления Мастер ASP.NET и CreateUserWizard поддерживают шаблоны, позволяющие определить html-код, который они отрисовывают. (CreateUserWizard является производным от wizard.) В следующем примере показана разметка для полностью шаблонного элемента управления CreateUserWizard :
<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="0">
<HeaderTemplate>
</HeaderTemplate>
<SideBarTemplate>
</SideBarTemplate>
<StepNavigationTemplate>
</StepNavigationTemplate>
<StartNavigationTemplate>
</StartNavigationTemplate>
<FinishNavigationTemplate>
</FinishNavigationTemplate>
<WizardSteps>
<asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server">
<ContentTemplate>
</ContentTemplate>
<CustomNavigationTemplate>
</CustomNavigationTemplate>
</asp:CreateUserWizardStep>
<asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CompleteWizardStep>
</WizardSteps>
</asp:CreateUserWizard>
Элемент управления отображает HTML-код следующим образом:
<table cellspacing="0" cellpadding="0" border="0" id="CreateUserWizard1" style="border-collapse:collapse;">
<tr>
<td>Header</td>
</tr>
<tr style="height:100%;">
<td>
<table cellspacing="0" cellpadding="0" border="0" style="height:100%;width:100%;border-collapse:collapse;">
<tr>
<td style="height:100%;width:100%;"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td align="right"></td>
</tr>
</table>
В ASP.NET 3.5 с пакетом обновления 1 (SP1) вы можете изменить содержимое шаблона, но по-прежнему имеете ограниченный контроль над выходными данными элемента управления Мастера . В ASP.NET 4 можно создать шаблон LayoutTemplate и вставить элементы управления PlaceHolder (с помощью зарезервированных имен), чтобы указать способ отрисовки элемента управления "Мастер ". Это иллюстрируется в примере ниже.
<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="1">
<LayoutTemplate>
<asp:PlaceHolder ID="headerPlaceholder" runat="server" />
<asp:PlaceHolder ID="sideBarPlaceholder" runat="server" />
<asp:PlaceHolder id="wizardStepPlaceholder" runat="server" />
<asp:PlaceHolder id="navigationPlaceholder" runat="server" />
</LayoutTemplate>
<HeaderTemplate>
Header
</HeaderTemplate>
<WizardSteps>
<asp:CreateUserWizardStep runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CreateUserWizardStep>
<asp:CompleteWizardStep runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CreateUserWizardStep>
</WizardSteps>
</asp:CreateUserWizard>
Пример содержит следующие именованные заполнители в элементе LayoutTemplate :
- headerPlaceholder — во время выполнения он заменяется содержимым элемента HeaderTemplate .
- sideBarPlaceholder — во время выполнения он заменяется содержимым элемента SideBarTemplate .
- wizardStepPlaceHolder — во время выполнения он заменяется содержимым элемента WizardStepTemplate .
- navigationPlaceholder — во время выполнения он заменяется любыми определенными шаблонами навигации.
Разметка в примере, использующая заполнители, отображает следующий HTML-код (без содержимого, фактически определенного в шаблонах):
<span>
</span>
Единственным HTML-кодом, который теперь не определен пользователем, является элемент span . (Мы ожидаем, что в будущих выпусках даже элемент span не будет отображаться.) Теперь вы получаете полный контроль над практически всем содержимым, созданным элементом управления "Мастер ".
ASP.NET MVC 3
ASP.NET MVC был представлен в качестве дополнительной платформы для ASP.NET 3.5 с пакетом обновления 1 (SP1) в марте 2009 года. Visual Studio 2010 включает ASP.NET MVC 2, который включает новые функции и возможности.
Поддержка областей
Области позволяют группировать контроллеры и представления в разделы большого приложения в относительной изоляции от других разделов. Каждая область может быть реализована как отдельный ASP.NET проект MVC, на который затем может ссылаться main приложение. Это помогает управлять сложностью при создании большого приложения и упрощает совместную работу нескольких команд над одним приложением.
Поддержка проверки атрибутов Data-Annotation
Атрибуты DataAnnotations позволяют присоединять логику проверки к модели с помощью атрибутов метаданных. Атрибуты DataAnnotations появились в ASP.NET динамических данных в ASP.NET 3.5 с пакетом обновления 1 (SP1). Эти атрибуты были интегрированы в связыватель модели по умолчанию и предоставляют средства на основе метаданных для проверки введенных пользователем данных.
Шаблонные вспомогательные функции
Шаблонные вспомогательные функции позволяют автоматически связывать шаблоны редактирования и отображения с типами данных. Например, можно использовать вспомогательное средство шаблона, чтобы указать, что элемент пользовательского интерфейса средства выбора даты автоматически отображается для значения System.DateTime . Это похоже на шаблоны полей в ASP.NET динамических данных.
Вспомогательные методы Html.EditorFor и Html.DisplayFor имеют встроенную поддержку отрисовки стандартных типов данных, а также сложных объектов с несколькими свойствами. Они также настраивают отрисовку, позволяя применять атрибуты заметок к данным, такие как DisplayName и ScaffoldColumn , к объекту ViewModel .
Часто требуется дополнительно настроить выходные данные из вспомогательных элементов пользовательского интерфейса и получить полный контроль над создаваемыми элементами. Вспомогательные методы Html.EditorFor и Html.DisplayFor поддерживают это с помощью механизма шаблонов, который позволяет определять внешние шаблоны, которые могут переопределять отображаемые выходные данные и управлять ими. Шаблоны можно визуализировать по отдельности для класса.
динамические данные
Динамические данные появились в выпуске платформа .NET Framework 3.5 с пакетом обновления 1 (SP1) в середине 2008 года. Эта функция предоставляет множество усовершенствований для создания приложений, управляемых данными, в том числе:
- Интерфейс RAD для быстрого создания веб-сайта, управляемого данными.
- Автоматическая проверка, основанная на ограничениях, определенных в модели данных.
- Возможность легко изменять разметку, созданную для полей в элементах управления GridView и DetailsView , с помощью шаблонов полей, которые являются частью проекта динамических данных.
Примечание
Примечание. Дополнительные сведения см. в документации по динамическим данным в библиотека MSDN.
Для ASP.NET 4 динамические данные были улучшены, чтобы предоставить разработчикам еще больше возможностей для быстрого создания веб-сайтов, управляемых данными.
Включение динамических данных для существующих проектов
Функции динамических данных, поставляемые в платформа .NET Framework 3.5 с пакетом обновления 1 (SP1), добавили новые функции, такие как:
- Шаблоны полей — предоставляют шаблоны на основе типов данных для элементов управления с привязкой к данным. Шаблоны полей предоставляют более простой способ настройки внешнего вида элементов управления данными, чем использование полей шаблонов для каждого поля.
- Проверка — динамические данные позволяют использовать атрибуты классов данных для указания проверки для распространенных сценариев, таких как обязательные поля, проверка диапазона, проверка типов, сопоставление шаблонов с помощью регулярных выражений и пользовательская проверка. Проверка выполняется элементами управления данными.
Однако к этим функциям предъявлялись следующие требования:
- Уровень доступа к данным должен быть основан на Entity Framework или LINQ to SQL.
- Единственными элементами управления источником данных, поддерживаемыми для этих функций, были элементы управления EntityDataSource или LinqDataSource .
- Для компонентов требуется веб-проект, созданный с помощью шаблонов динамических данных или сущностей динамических данных, чтобы иметь все файлы, необходимые для поддержки этой функции.
Основной целью поддержки динамических данных в ASP.NET 4 является включение новых функций динамических данных для любого приложения ASP.NET. В следующем примере показана разметка для элементов управления, которые могут использовать функциональные возможности динамических данных на существующей странице.
<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True"
DataKeyNames="ProductID" DataSourceID="LinqDataSource1">
</asp:GridView>
<asp:LinqDataSource ID="LinqDataSource1" runat="server"
ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True"
EnableUpdate="True" TableName="Products">
</asp:LinqDataSource>
Чтобы включить поддержку динамических данных для этих элементов управления, в код страницы необходимо добавить следующий код:
GridView1.EnableDynamicData(typeof(Product));
Когда элемент управления GridView находится в режиме редактирования, динамические данные автоматически проверяют, что введенные данные в правильном формате. Если это не так, отображается сообщение об ошибке.
Эта функция также предоставляет другие преимущества, такие как возможность указывать значения по умолчанию для режима вставки. Без динамических данных для реализации значения по умолчанию для поля необходимо присоединиться к событию, найти элемент управления (с помощью FindControl) и задать его значение. В ASP.NET 4 вызов EnableDynamicData поддерживает второй параметр, который позволяет передавать значения по умолчанию для любого поля объекта , как показано в следующем примере:
DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });
Декларативный синтаксис элемента управления DynamicDataManager
Элемент управления DynamicDataManager был улучшен, так что его можно настроить декларативно, как и большинство элементов управления в ASP.NET, а не только в коде. Разметка для элемента управления DynamicDataManager выглядит следующим образом:
<asp:DynamicDataManager ID="DynamicDataManager1" runat="server"
AutoLoadForeignKeys="true">
<DataControls>
<asp:DataControlReference ControlID="GridView1" />
</DataControls>
</asp:DynamicDataManager>
<asp:GridView id="GridView1" runat="server"
</asp:GridView>
Эта разметка обеспечивает поведение динамических данных для элемента управления GridView1, на который ссылается раздел DataControls элемента управления DynamicDataManager .
Шаблоны сущностей
Шаблоны сущностей предлагают новый способ настройки макета данных без необходимости создавать настраиваемую страницу. Шаблоны страниц используют элемент управления FormView (вместо элемента управления DetailsView , который использовался в шаблонах страниц в более ранних версиях динамических данных) и элемент управления DynamicEntity для отображения шаблонов сущностей. Это обеспечивает больший контроль над разметкой, отображаемой динамическими данными.
В следующем списке показан новый макет каталога проекта, содержащий шаблоны сущностей:
\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx
Каталог EntityTemplate содержит шаблоны для отображения объектов модели данных. По умолчанию объекты отрисовываются с помощью Default.ascx шаблона, который предоставляет разметку, похожую на разметку, созданную элементом управления DetailsView , используемым динамическими данными в ASP.NET 3.5 с пакетом обновления 1 (SP1). В следующем примере показана разметка Default.ascx для элемента управления :
<asp:EntityTemplate runat="server" ID="TemplateContainer1">
<ItemTemplate>
<tr
<td>
<asp:Label ID="Label1" runat="server" OnInit="Label_Init" />
</td>
<td>
<asp:DynamicControl runat="server" OnInit="DynamicControl_Init" />
</td>
</tr>
</ItemTemplate>
</asp:EntityTemplate>
Шаблоны по умолчанию можно изменить, чтобы изменить внешний вид всего сайта. Существуют шаблоны для операций отображения, редактирования и вставки. Новые шаблоны можно добавлять на основе имени объекта данных, чтобы изменить внешний вид объекта только одного типа. Например, можно добавить следующий шаблон:
\DynamicData\EntityTemplates\Products.aspx
Шаблон может содержать следующую разметку:
<tr>
<td>Name</td>
<td><asp:DynamicControl runat="server" DataField="ProductName" /></td>
<td>Category</td>
<td><asp:DynamicControl runat="server" DataField="Category" /></td>
</tr>
Новые шаблоны сущностей отображаются на странице с помощью нового элемента управления DynamicEntity . Во время выполнения этот элемент управления заменяется содержимым шаблона сущности. В следующей разметке показан элемент управления FormView в шаблоне Detail.aspx страницы, который использует шаблон сущности. Обратите внимание на элемент DynamicEntity в разметке.
<asp:FormView runat="server" ID="FormView1"
DataSourceID="DetailsDataSource"
OnItemDeleted="FormView1_ItemDeleted">
<ItemTemplate>
<table class="DDDetailsTable" cellpadding="6">
<asp:DynamicEntity runat="server" />
<tr class="td">
<td colspan="2">
<asp:DynamicHyperLink ID="EditHyperLink" runat="server"
Action="Edit" Text="Edit" />
<asp:LinkButton ID="DeleteLinkButton" runat="server"
CommandName="Delete"
CausesValidation="false"
OnClientClick='return confirm("Are you sure you want to delete this item?");'
Text="Delete" />
</td>
</tr>
</table>
</ItemTemplate>
</asp:FormView>
Новые шаблоны полей для URL-адресов и адресов Email
ASP.NET 4 представлено два новых встроенных шаблона полей: EmailAddress.ascx и Url.ascx. Эти шаблоны используются для полей, помеченных как EmailAddress или URL-адрес с атрибутом DataType . Для объектов EmailAddress поле отображается в виде гиперссылки, созданной с помощью протокола mailto: . Когда пользователь щелкает ссылку, открывается почтовый клиент пользователя и создается шаблон сообщения. Объекты, типизированные как URL-адрес , отображаются как обычные гиперссылки.
В следующем примере показано, как будут помечаться поля.
[DataType(DataType.EmailAddress)]
public object HomeEmail { get; set; }
[DataType(DataType.Url)]
public object Website { get; set; }
Создание ссылок с помощью элемента управления DynamicHyperLink
Динамические данные используют новую функцию маршрутизации, добавленную в платформа .NET Framework 3.5 с пакетом обновления 1 (SP1), для управления URL-адресами, которые пользователи видят при доступе к веб-сайту. Новый элемент управления DynamicHyperLink упрощает создание ссылок на страницы на сайте динамических данных. В следующем примере показано, как использовать элемент управления DynamicHyperLink :
<asp:DynamicHyperLink ID="ListHyperLink" runat="server"
Action="List" TableName="Products">
Show all products
</asp:DynamicHyperLink>
Эта разметка создает ссылку, которая указывает на страницу Список для Products таблицы на основе маршрутов, определенных Global.asax в файле . Элемент управления автоматически использует имя таблицы по умолчанию, на котором основана страница динамических данных.
Поддержка наследования в модели данных
Entity Framework и LINQ to SQL поддерживают наследование в своих моделях данных. Примером этого может быть база данных с таблицей InsurancePolicy . Он также может содержать CarPolicy таблицы и HousePolicy , которые имеют те же поля, что и , а InsurancePolicy затем добавить дополнительные поля. Динамические данные были изменены для понимания унаследованных объектов в модели данных и поддержки формирования шаблонов для наследуемых таблиц.
Поддержка связей "многие ко многим" (только Entity Framework)
Платформа Entity Framework обладает широкими возможностями поддержки связей "многие ко многим" между таблицами, которая реализуется путем предоставления связи в виде коллекции в объекте Entity . Добавлены новые ManyToMany.ascx шаблоны полей и ManyToMany_Edit.ascx , обеспечивающие поддержку отображения и редактирования данных, участвующих в связях "многие ко многим".
Новые атрибуты для управления отображением и поддержкой перечислений
Добавлен элемент DisplayAttribute , который предоставляет дополнительный контроль над отображением полей. Атрибут DisplayName в более ранних версиях динамических данных позволял изменять имя, используемое в качестве подпись для поля. Новый класс DisplayAttribute позволяет указать дополнительные параметры для отображения поля, например порядок отображения поля и то, будет ли поле использоваться в качестве фильтра. Атрибут также предоставляет независимый контроль над именем, используемым для меток в элементе управления GridView , именем, используемым в элементе управления DetailsView , текстом справки для поля и подложкой, используемой для поля (если поле принимает текстовый ввод).
Добавлен класс EnumDataTypeAttribute , позволяющий сопоставлять поля с перечислениями. При применении этого атрибута к полю указывается тип перечисления. Динамические данные используют новый Enumeration.ascx шаблон поля для создания пользовательского интерфейса для отображения и изменения значений перечисления. Шаблон сопоставляет значения из базы данных с именами в перечислении .
Расширенная поддержка фильтров
Dynamic Data 1.0 поставляется со встроенными фильтрами для логических столбцов и столбцов с внешним ключом. Фильтры не позволяют указать, были ли они отображены или в каком порядке они отображались. Новый атрибут DisplayAttribute решает обе эти проблемы, позволяя управлять отображением столбца в качестве фильтра и в каком порядке он будет отображаться.
Дополнительное улучшение заключается в том, что поддержка фильтрации была повторно написана для использования новой функции веб-формы. Это позволяет создавать фильтры, не требуя знания об элементе управления источником данных, с которым будут использоваться фильтры. Наряду с этими расширениями фильтры также были преобразованы в элементы управления шаблонов, что позволяет добавлять новые. Наконец, класс DisplayAttribute, упомянутый ранее, позволяет переопределить фильтр по умолчанию так же, как UIHint позволяет переопределить шаблон поля по умолчанию для столбца.
Улучшения веб-разработки в Visual Studio 2010
Веб-разработка в Visual Studio 2010 была улучшена для повышения совместимости CSS, повышения производительности с помощью HTML и ASP.NET фрагментов разметки и нового динамического JavaScript IntelliSense.
Улучшенная совместимость CSS
Конструктор Visual Web Developer в Visual Studio 2010 был обновлен для улучшения соответствия стандартам CSS 2.1. Конструктор лучше сохраняет целостность источника HTML и надежнее, чем в предыдущих версиях Visual Studio. Кроме того, были внесены улучшения архитектуры, которые позволят улучшить отрисовку, макет и удобство обслуживания в будущем.
Фрагменты кода HTML и JavaScript
В редакторе HTML IntelliSense автоматически заполняет имена тегов. Функция фрагментов кода IntelliSense автоматически завершает целые теги и многое другое. В Visual Studio 2010 фрагменты intelliSense поддерживаются для JavaScript, а также C# и Visual Basic, которые поддерживались в более ранних версиях Visual Studio.
Visual Studio 2010 включает более 200 фрагментов кода, которые помогают автоматически заполнить общие теги ASP.NET и HTML, включая обязательные атрибуты (такие как runat="server") и общие атрибуты, относящиеся к тегу (например, ID, DataSourceID, ControlToValidate и Text).
Вы можете скачать дополнительные фрагменты кода или написать собственные фрагменты, которые инкапсулируют блоки разметки, используемые вами или вашей командой для распространенных задач.
Улучшения IntelliSense для JavaScript
В Visual 2010 технология IntelliSense для JavaScript была переработана, чтобы обеспечить еще более широкие возможности редактирования. IntelliSense теперь распознает объекты, которые были динамически созданы такими методами, как registerNamespace , и аналогичными методами, используемыми другими платформами JavaScript. Повышена производительность для анализа больших библиотек скриптов и отображения IntelliSense с небольшой задержкой обработки или без нее. Совместимость значительно повышена для поддержки почти всех сторонних библиотек и поддержки различных стилей программирования. Комментарии к документации теперь анализируются по мере ввода и немедленно используются IntelliSense.
Развертывание веб-приложений с помощью Visual Studio 2010
Когда ASP.NET разработчики развертывают веб-приложение, они часто обнаруживают следующие проблемы:
- Для развертывания на общем сайте размещения требуются такие технологии, как FTP, что может быть медленным. Кроме того, необходимо вручную выполнять такие задачи, как запуск скриптов SQL для настройки базы данных, и изменить параметры IIS, например настроить папку виртуального каталога в качестве приложения.
- В корпоративной среде помимо развертывания файлов веб-приложения администраторам часто приходится изменять файлы конфигурации ASP.NET и параметры IIS. Чтобы запустить базу данных приложения, администраторы базы данных должны выполнить серию скриптов SQL. Такие установки являются трудоемкими, часто занимают несколько часов и должны быть тщательно задокументированы.
Visual Studio 2010 включает технологии, которые устраняют эти проблемы и позволяют легко развертывать веб-приложения. Одной из этих технологий является средство веб-развертывания IIS (MsDeploy.exe).
Функции веб-развертывания в Visual Studio 2010 включают следующие основные области:
- Веб-упаковка
- преобразование Web.config
- Развертывание баз данных
- Публикация одним щелчком для веб-приложений
В следующих разделах содержатся сведения об этих функциях.
Веб-упаковка
Visual Studio 2010 использует средство MSDeploy для создания сжатого (.zip) файла для приложения, который называется веб-пакетом. Файл пакета содержит метаданные о приложении, а также следующее содержимое:
- Параметры IIS, в том числе параметры пула приложений, параметры страницы ошибок и т. д.
- Фактическое веб-содержимое, которое включает веб-страницы, пользовательские элементы управления, статическое содержимое (изображения и HTML-файлы) и т. д.
- SQL Server схемы и данные базы данных.
- Сертификаты безопасности, компоненты для установки в GAC, параметры реестра и т. д.
Веб-пакет можно скопировать на любой сервер, а затем установить вручную с помощью диспетчера IIS. Кроме того, для автоматического развертывания пакет можно установить с помощью команд командной строки или API развертывания.
Visual Studio 2010 предоставляет встроенные задачи и целевые объекты MSBuild для создания веб-пакетов. Дополнительные сведения см . в ASP.NET обзоре развертывания проекта веб-приложения на веб-сайте MSDN и 10 + 20 причин, по которым следует создать веб-пакет в блоге Vishal Joshi.
Преобразование Web.config
Для развертывания веб-приложений в Visual Studio 2010 представлено преобразование xml-документов (XDT), которое позволяет преобразовать Web.config файл из параметров разработки в рабочие. Параметры преобразования задаются в файлах преобразования с именами web.debug.config, web.release.configи т. д. (Имена этих файлов соответствуют конфигурациям MSBuild.) Файл преобразования включает только те изменения, которые необходимо внести в развернутый Web.config файл. Изменения задаются с помощью простого синтаксиса.
В следующем примере показана часть web.release.config файла, которая может быть создана для развертывания конфигурации выпуска. Ключевое слово Replace в примере указывает, что во время развертывания узел connectionString в Web.config файле будет заменен значениями, перечисленными в примере.
<connectionStrings xdt:Transform="Replace">
<add name="BlogDB" connectionString="connection string detail]" />
</connectionStrings>
Дополнительные сведения см. в статье Синтаксис преобразованияWeb.config для развертывания проекта веб-приложения на веб-сайте MSDN иВеб-развертывание: преобразование Web.Config в блоге Vishal Joshi.
Развертывание баз данных
Пакет развертывания Visual Studio 2010 может включать зависимости от SQL Server баз данных. В рамках определения пакета вы предоставляете строка подключения для базы данных-источника. При создании веб-пакета Visual Studio 2010 создает скрипты SQL для схемы базы данных и при необходимости для данных, а затем добавляет их в пакет. Вы также можете предоставить пользовательские скрипты SQL и указать последовательность, в которой они должны выполняться на сервере. Во время развертывания вы предоставляете строка подключения, подходящий для целевого сервера. Затем процесс развертывания использует этот строка подключения для запуска скриптов, создающих схему базы данных и добавляющих данные.
Кроме того, одним щелчком мыши можно настроить развертывание для публикации базы данных непосредственно при публикации приложения на удаленном сайте общего размещения. Дополнительные сведения см. в статье Практическое руководство. Развертывание базы данных с помощью проекта веб-приложения на веб-сайте MSDN и Развертывание базы данных с помощью VS 2010 в блоге Vishal Joshi.
публикация One-Click для веб-приложений
Visual Studio 2010 также позволяет использовать службу удаленного управления IIS для публикации веб-приложения на удаленном сервере. Вы можете создать профиль публикации для учетной записи размещения, а также для тестовых серверов или промежуточных серверов. Каждый профиль может безопасно сохранять соответствующие учетные данные. Затем можно выполнить развертывание на любом из целевых серверов одним щелчком с помощью панели инструментов веб-публикации одним щелчком. В Visual Studio 2010 вы также можете выполнять публикацию с помощью командной строки MSBuild. Это позволяет настроить среду командной сборки так, чтобы она включала публикацию в модель непрерывной интеграции.
Дополнительные сведения см. в статьях Практическое руководство. Развертывание проекта веб-приложения с помощью One-Click публикации и веб-развертывания на веб-сайте MSDN и Веб-публикация с помощью VS 2010 в блоге Vishal Joshi. Чтобы просмотреть видеопрезентирования о развертывании веб-приложений в Visual Studio 2010, см. статью Vs 2010 for Web Developer Previews в блоге Vishal Joshi.
Ресурсы
Следующие веб-сайты содержат дополнительные сведения о ASP.NET 4 и Visual Studio 2010.
- ASP.NET 4 — официальная документация по ASP.NET 4 на веб-сайте MSDN.
- https://www.asp.net/ — собственный веб-сайт команды ASP.NET.
- https://www.asp.net/dynamicdata/ и ASP.NET карта динамического содержимого данных — сетевые ресурсы на сайте группы ASP.NET и в официальной документации по ASP.NET динамическим данным.
- https://www.asp.net/ajax/— веб-ресурс main для разработки ASP.NET Ajax.
- https://devblogs.microsoft.com/dotnet/category/aspnet/ — Блог группы разработчиков Visual Web, в котором содержатся сведения о функциях Visual Studio 2010.
- ASP.NET WebStack — веб-ресурс main для предварительных выпусков ASP.NET.
Отказ от ответственности
Это предварительный документ, он может быть существенно изменен до выхода окончательного коммерческого выпуска описанного здесь программного обеспечения.
Информация, содержащаяся в этом документе, являет собой текущее представление корпорации Майкрософт о вопросах, которые обсуждались на момент публикации. Поскольку корпорация Майкрософт должна реагировать на изменение рыночных условий, эта информация не должна рассматриваться как обязательство корпорации Майкрософт. Корпорация Майкрософт не может гарантировать достоверность информации, предоставленной после момента публикации.
Данный технический документ предназначен только для ознакомительных целей. МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПРЕДУСМОТРЕННЫХ ЗАКОНОДАТЕЛЬСТВОМ, ОТНОСИТЕЛЬНО СВЕДЕНИЙ, СОДЕРЖАЩИХСЯ В ДАННОМ ДОКУМЕНТЕ.
Ответственность за соблюдение всех авторских прав и прав на интеллектуальную собственность целиком и полностью несет пользователь. Без ограничения авторских прав ни одна из частей этого документа не может быть воспроизведена, сохранена или использована в системах поиска либо передана в любой форме, любыми способами (электронными, механическими, в виде фотокопии, в виде записи или любыми другими) и для любых целей без письменного разрешения корпорации Майкрософт.
Корпорация Майкрософт может иметь патенты, патентные заявки, охраняемые товарные знаки, авторские или другие права на интеллектуальную собственность применительно к содержимому этого документа. Без письменного разрешения корпорации Майкрософт данный документ не дает лицензии на эти патенты, охраняемые товарные знаки, авторские права и другую интеллектуальную собственность.
Если не указано иное, приведенные здесь примеры компаний, организаций, продуктов, доменных имен, адресов электронной почты, логотипов, людей, мест и событий являются вымышленными, и никакой связи с какой-либо реальной компанией, организацией, продуктом, доменным именем, адресом электронной почты, логотипом, человеком, местом или событием не предполагается или не следует выводить.
© 2009 Корпорация Майкрософт. Все права защищены.
Microsoft и Windows являются охраняемыми товарными знаками корпорации Майкрософт в США и других странах.
Названия фактических компаний и продуктов, упомянутые здесь, могут являться охраняемыми товарными знаками соответствующих владельцев.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по