Кэширование на уровне страниц ASP.NET (с проверенными сайтами) - PullRequest
5 голосов
/ 19 января 2009

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

Если вы не активируете аутентификацию без файлов cookie (тогда идентификатор сессии становится частью URL-адреса), все пользователи будут видеть одну и ту же кэшированную страницу (независимо от того, кто они).

Это правильно?

Ответы [ 4 ]

4 голосов
/ 19 января 2009

Да, вы на 100% правы в этом вопросе.

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

Затем вы можете использовать Session или другое хранилище кеша, если вам необходимо кешировать данные, специфичные для пользователя.

3 голосов
/ 19 января 2009

Другой вариант - «Кэширование пончиков», как его называет Скотт Гатри:

Внедрение «Кеширования пончиков» с помощью функции замены кэша вывода ASP.NET 2.0

Это позволяет вам кэшировать на уровне страницы, в то же время реализуя определенные элементы в не кешированных «дырах».

3 голосов
/ 19 января 2009

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

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

<asp:Substitution ID="mySubstitution" runat="server" MethodName="GetLoggeninUserName" />
0 голосов
/ 28 января 2009

Да, вы правы, и контроль замещения, отмеченный Энди (и Zhaph), является вашим лучшим ответом, если вы используете ASP.NET 2.0 или выше. Создание отдельных пользовательских элементов управления для контента, не относящегося к конкретному пользователю, является менее идеальным подходом, который следует использовать, только если вы застряли в работе с ASP.NET v1.x (поэтому, я думаю, вы должны отметить Энди как ответ).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...