Похоже, вы пытаетесь решить проблему пропускной способности.Уже одно это говорит о том, что вы не должны хранить больше, чем нужно (т.е. идентификатор сессии) в куки.
Существуют две основные проблемы (среди прочих) для использования куки.1) Они отправляются при каждом запросе. 2) Вы можете хранить только ограниченный объем информации.
В общем, доверять всему, что пользователь дает вам (включая зашифрованные файлы cookie), плохо.
Сколько одновременных пользователей вы ожидаете иметь на своем сайте?Имейте в виду, что база данных сможет кэшировать определенные вызовы.Кроме того, если вы используете ORM, такой как nhibernate, вы получите там кэширование 2-го уровня.Если ничего не помогло, вы могли бы использовать управление сеансом в памяти?
Самая большая проблема, которую я имею при помещении идентификатора пользователя в cookie, - это энтропия этого ключа.Скажите, что ваш userId - это электронная почта.Все, что я должен сделать как злоумышленник, - угадать идентификатор пользователя, действительный в вашей системе, и я «автоматически» стану этим пользователем.Причина, по которой люди используют sessionID, а затем извлекают пользователя, состоит в том, что теоретически sessionID сложнее угадать.
Я бы предложил использовать управление сеансами базы данных, если вы находитесь в ситуации с балансировкой нагрузки.Если нет, используйте в памяти.Это быстро.Память дешевая.И если вы не сохраняете 10 МБ данных в сеансе для каждого пользователя и у вас есть 10000 пользователей, у вас все будет хорошо.
Как сказал Кен, вам, вероятно, следует использовать стандартные доступные теги [authorize]с MVC в отличие от создания собственного метода.