Является ли ваша причина для сохранения вызова базы данных каждый раз, когда вам нужен идентификатор пользователя? Если это так, когда я использую ASP.NET MembershipProvider, я обычно делаю либо собственного провайдера, который позволяет мне кэшировать этот вызов, либо вспомогательный метод, который я могу кэшировать.
Если вы думаете о том, чтобы поместить его в профиль, я не вижу особой причины для этого, тем более что для этого также потребуется вызов базы данных, и, если вы не используете там собственного провайдера профиля, у него есть добавлена обработка разбора UserId.
Если вам интересно, почему они не реализовали метод GetUserId, это просто потому, что вы не всегда гарантируете, что этот идентификатор пользователя будет GUID, как во включенном поставщике.
EDIT:
См. статью ScottGu о провайдерах , в которой содержится ссылка на загрузку фактического исходного кода, т. Е. SqlMembershipProvider .
Но самое простое, что можно сделать на самом деле, - это метод GetUserId () в вашем пользовательском объекте или служебный класс, где вы получаете UserId из кэша / сеанса, если он есть, в противном случае попадаете в базу данных, кэшируете его по имени пользователя (или сохраняете в сеанс) и верните его.
Для более подробного рассмотрения (но будьте очень осторожны из-за ограничений размера файлов cookie): Проверка подлинности форм: членство, роли и профиль без провайдеров и без сеанса