Ролевые стратегии кэширования в ASP.NET MVC
Это применяется только для внешних вызывающих абонентов. Помните, что можно назвать статический метод базового класса, таким образом, что-то вроде этого допустимо:
class Foo
{
public static void Do() { Console.WriteLine("Foo.Do"); }
}
class Bar : Foo // :Foo added
{
public static void Something()
{
Do();
}
}
Поэтому предупреждение говорит Вам помещать новое, Вы хотите избежать любого беспорядка при выполнении этого:
class Foo
{
public static void Do() { Console.WriteLine("Foo.Do"); }
}
class Bar : Foo // :Foo added
{
public static void Something()
{
Do();
}
public static new void Do() { Console.WriteLine("Bar.Do"); }
}
3 ответа
Если вы разработали свой собственный класс RoleProvider, вы можете выполнять собственное кэширование данных, например, используя кеш ASP.NET. Это более гибкий подход, чем использование сеанса в качестве кеша, поскольку он будет работать даже на страницах, для которых не включено состояние сеанса.
Я не согласен с комментарием Вятта Барнетта о том, что:
Недостаток использования сеанса ... тот факт, что хранилище сеансов очень нарушать и не особо надежный
Это нормально, если кеш (сеанс, ASP.NET Cache или что-то еще) является изменчивым - вам просто нужно повторно заполнить его, когда это необходимо.
Чтобы ответить на ваши вопросы:
Это так же безопасно, как шифрование, используемое для шифрования cookie. Если вы полагаетесь на FormsAuthentication, он должен быть не менее безопасным, чем билет проверки подлинности с помощью форм.
Файл cookie будет передаваться с каждым запросом. Таким образом, существует потенциальное снижение производительности, если у пользователей может быть очень большое количество ролей, и вероятность превышения максимального размера файлов cookie, поддерживаемого браузером.
Хотя идея о том, что каждый запрос к БД неэффективна, верна, но помните, что производительность SELECT для правильно проиндексированных таблиц в современных БД невероятно высока, поэтому я сначала сделаю некоторые измерения, чтобы быть уверенным. что этот сценарий на самом деле отрицательно влияет на производительность, а теоретически может отрицательно повлиять на производительность позже.
Обратной стороной использования сеанса являются не столько накладные расходы (минимальные), сколько тот факт, что хранилище сеансов очень ненадежно и не очень надежно. Например, вы можете легко потерять сеанс и по-прежнему иметь зарегистрированного пользователя.
Тем не менее, хороший способ остановиться посередине здесь - это кэшировать роли пользователя для каждого запроса с использованием коллекции HttpContext.Items. Это ограничит один запрос SELECT, что, вероятно, является достаточно эффективным (см. измерения выше), избегая при этом других проблем с хранением, таких как жирный, небезопасный файл cookie или какое-либо, скорее, нарушающее решение на основе сеанса.
Фактически, информация cookie будет отправляться из браузера на ваш веб-сервер с каждым запросом, именно так и работают файлы cookie, но пока размер файла cookie является разумным, он не должен сильно влиять на производительность. Если вы используете аутентификацию с помощью форм, я бы рекомендовал сохранить роли в cookie аутентификации с помощью форм, как описано в этой записи блога . В этом случае вы просто добавляете данные в уже существующий файл cookie.