Свойство AsyncRendering в элементе управления ASP.Net ReportViewer является одним из наиболее неправильно понятых свойств в ReportViewer. И это наша вина. Существует множество побочных эффектов при настройке этого свойства, которые вы не ожидаете от имени. Фактически, большую часть времени я вижу, как пользователи устанавливают это свойство, они делают это для побочных эффектов, а не для его истинного намерения. Эти побочные эффекты исчезли в Visual Studio 2010, потому что вы можете получить нужные эффекты в любом режиме. Но чтобы понять, как все изменилось, давайте сначала рассмотрим некоторую справочную информацию.
Намерение AsyncRendering
Традиционно HTML-код веб-страницы не отправляется в браузер до тех пор, пока все веб-элементы управления на странице не сгенерируют свое содержимое. Для элементов управления, таких как текстовые поля и кнопки, это имеет смысл. Но ReportViewer гораздо сложнее. Для создания HTML-кода отчета зрителю может потребоваться много времени. В большинстве случаев имеет смысл отправить оставшуюся часть страницы обратно в браузер, а затем сделать еще один запрос для асинхронного получения содержимого отчета. Это позволяет пользователю взаимодействовать с остальной частью страницы, а также видеть «индикатор загрузки», чтобы они знали, что сервер что-то делает. Это поведение по умолчанию - AsyncRendering = true.
Но есть также случаи, когда вы хотите заблокировать всю страницу, пока отчет не будет обработан. Хорошим примером является страница типа панели инструментов, которая отображает несколько небольших отчетов, возможно, каждый из которых содержит одну диаграмму или небольшую таблицу. В этом случае вы можете не захотеть, чтобы пользователь был засыпан несколькими индикаторами ожидания. Если вы знаете, что отчеты быстро обрабатываются, лучше всего заблокировать страницу на короткое время. Это намерение AsyncRendering = false.
Асинхронный режим в Visual Studio 2005 и 2008
Выбранный вами режим оказывает существенное влияние на генерируемый HTML. Элемент управления ReportViewer изначально разрабатывался задолго до появления ASP.Net AJAX. Когда вы представляете отчет синхронно, HTML-код для содержимого отчета внедряется непосредственно на всю страницу. Но при рендеринге асинхронно ReportViewer использует фрейм. Содержимое фрейма извлекается браузером отдельно от главной страницы, поэтому оно позволяет видеть главную страницу, пока отчет генерируется в отдельном запросе к веб-серверу.
Кадры являются корнем всех побочных эффектов AsyncRendering. Использование кадров приводит к следующим различиям между двумя режимами:
Карта документа видна только в асинхронном режиме, отчасти потому, что она опирается на фреймы для обработки изменения размера относительно области отчета.
Поскольку отчет отображается во фрейме и не является частью страницы ASP.Net, на которой размещается средство просмотра, разработчики не имеют возможности обрабатывать события, возникающие при обработке отчета. Наиболее частая жалоба, которую мы получаем в этой области, - это невозможность обработать событие ReportError при асинхронном рендеринге.
Размер кадра трудно рассчитать для зрителя, и поэтому он обычно неверен. Он основан на режиме изменения размера программы просмотра (в процентах или фиксированном размере), высоте панели инструментов и наличии параметров. Это основная причина появления чрезмерного количества полос прокрутки в средстве просмотра, особенно при использовании стандартного режима или браузеров без IE. Разработчики часто переключаются на синхронный рендеринг, чтобы облегчить это.
Вместестрока, аналогичная размеру кадра, заключается в том, что свойство SizeToReportContent игнорируется в асинхронном режиме. Рамка не регулирует свой размер в зависимости от содержимого, поэтому нет простого способа показать произвольный отчет, встроенный в страницу без полос прокрутки, если вы не переключитесь в синхронный режим.
Эти побочные эффекты, как правило, имеют более высокий рейтинг с точки зрения требований при создании приложения, чем когда отчет отображается синхронно. Поэтому неудивительно, что эти проблемы стали движущим фактором, который выбирают разработчики режимов.
История в Visual Studio 2010
Одной из самых больших функций ASP.Net ReportViewer в VS 2010 является тот факт, что он сильно зависит от ASP.Net AJAX. По умолчанию программа просмотра будет использовать асинхронные обратные вызовы для всех своих операций. Это означает, что нам больше не нужно полагаться на фреймы для асинхронного получения данных отчета с остальной части страницы ASP.Net. В VS 2010 после завершения загрузки отчета HTML-код, отображаемый в браузере, будет одинаковым независимо от того, используете ли вы синхронный или асинхронный рендеринг.
Все предыдущие побочные эффекты AsyncRendering теперь исчезли. Оба режима поддерживают карту документа. Оба режима поддерживают свойство SizeToReportContent. Асинхронные обратные передачи обычно обрабатываются так же, как традиционные обратные передачи, поэтому вы можете обрабатывать события, возникающие во время обработки отчета. И из-за большой работы, которую мы проделали в этом выпуске для стандартного режима рендеринга HTML и Firefox и Safari, вы никогда не должны видеть двойные (или тройные!) Полосы прокрутки в средстве просмотра.
В VS 2010 AsyncRendering вернулся к своему истинному намерению - он контролирует, блокирует ли начальная обработка отчета всю страницу ASP.Net и ничего больше.