MVC 3 с проверкой подлинности с помощью форм, нужен ID пользователя в проекте данных, лучшие практики?

Question

Я только начал проект MVC 3, используя проверку подлинности с помощью форм. У меня есть веб-проект (проект MVC) и проект данных. Проект данных обрабатывает все взаимодействия с базой данных.

Мне нужно хранить текущий идентификатор пользователя в моей базе данных при каждой вставке и обновлении.

Вот что я сейчас делаю. Я чувствую, что это должен быть общий сценарий. Может кто-нибудь пролить свет на лучший способ сделать это?

1. При входе в систему или при регистрации я беру свою текущую запись пользователя (по имени пользователя) из базы данных и сохраняю идентификатор пользователя в сессии.
2. При сохранении записи в моем проекте данных я ссылаюсь на httpcontext (если он существует) и использую идентификатор пользователя, который хранится в сеансе.

Это работает для всех, кроме одного сценария. Сбой происходит, когда у пользователя сохранен действительный файл cookie, и поэтому ему разрешено обойти действие входа в систему / регистрации. Когда это происходит, очевидно, что моя переменная сеанса для userId равна нулю. Следующим моим шагом будет создание базового контроллера и элемента OnAuthorizeStarting, чтобы проверить, является ли моя переменная Session нулевой или нет. Это кажется глупым, и я надеюсь, что есть лучший способ.

Я не хочу передавать идентификатор пользователя в проект данных в качестве параметра при каждом вызове сохранения.

У кого-нибудь есть блеск? спасибо.

Answer 1

Идентификатор пользователя доступен через членство. Итак, как-то так:

Membership.GetUser(HttpContext.User.Current.UserName).ProviderUserKey

IPrincipal (HttpContext.user.Current) создается, когда пользователь проходит проверку подлинности на основе файла cookie проверки подлинности форм. Вы просто извлекаете идентификатор пользователя из членства всякий раз, когда вам это нужно.

Если вам не нравится доступ к членству каждый раз, тогда вы всегда можете создать статический вспомогательный класс, который обернет ваш сеансовый вызов UserID. Если он нулевой, он отправляется поставщику членства, получает его, затем сохраняет его в сеансе ... при последующих обращениях он просто получает переменную сеанса.