ASP MVC против WebForms: с помощью SessionState для входа пользователя

Question

я вопрос, касающийся обработки входа пользователя при переносе приложения на MVC:

• в «старых» WebForm дней, разработчики просто использовали Объект SessionState, чтобы установить пользователя для входа в систему, например, просто помещая пользовательский объект в SessionState (и этот пользовательский объект содержит простые свойства, такие как name/lastlogon/etc.)

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

• да, я знаю, что это MembershipProvide-штучка, но я никогда не использовал его

Теперь, в MVC, все говорят мне, что «с помощью SessionStat для это плохо» и «приложения построены, что путь несовершенны в дизайне »и что« существует множество угроз безопасности »и т. д.

Я использовал этот метод, потому что он работал для приложения очень надежно, он был прост в реализации и охватывал все, что нам нужно.

(Конечно, есть вещь с процессом веб-рециркуляция рабочего и опорожнение сеанс - но это еще не проблема, в нашем случае, так как приложение работает для каждой страны на выделенной машине)

Я прочитал учебники, рассказывающие мне, чтобы они помещали этот материал в БД и -встречу - выполняли запрос в БД, чтобы проверить, зарегистрирован ли пользователь, за EACH запрос? Но: ни при каких обстоятельствах это не выполнимо, так как я хочу, чтобы запросы БД были минимальными.

Так что мой вопрос:

A), что не так с использованием так и в новом приложении MVC?

B) Каков наилучший способ справиться с этим сценарием в недавно созданном приложении MVC?

Что касается идеи session-in-DB: вместо этого я установил бы дополнительную службу, например «диспетчер сеансов», который получает запрос по сети, но такие простые запросы не должны БД - это не хорошая идея?

Любая идея, подсказка/etc. высоко ценится, так как этот сценарий действительно смущает меня: -X

Answer 1

A)

Фундаментальной в ASP.NET MVC Framework является то, что его без гражданства. Данные передаются с использованием HTTP-запросов и отправляются в представления в моделях viewmodels. Веб-формы пытались сохранить состояние с помощью viewstate и т. Д., Поэтому вы бы увидели зарегистрированного пользователя в сеансе. То, что не сказать, сессия не должна использоваться полностью в asp.net mvc, есть некоторые обстоятельства, когда это может быть полезно. Как и сохранение трехэтапного процесса формы, который должен сохраняться на последнем шаге. Но в целом у нас уже есть рекомендуемый способ для обработки логинов, и то forms authentication

B)

Для доступа к объекту пользователя, вы можете создать custom identity реализующий интерфейс IPrincipal и добавить необходимые пользовательские поля тебе нужно.Затем установите индивидуальный идентификатор в global filter и получите доступ к нему в результатах вашего действия. Что касается нежелания запрашивать базу данных для каждого запроса, почему бы вам просто не вызвать ее для первоначального запроса, тогда кешируйте результат до тех пор, пока пользователь не будет обновлен, когда вы затем сможете перезагрузить объект и снова установить его в пользовательском удостоверении.