Как связать данные моего приложения с пользователем в ASP.NET MemberShipProvider?

Question

Я только начинаю изучать ASP.NET MVC. Я работаю над проектом, созданным с помощью стандартного шаблона проекта, который по умолчанию использует SqlMembershipProvider. Это автоматически создало базу данных ASPNETDB.mdf в моем проекте для хранения информации о членстве. Как я могу связать членов, хранящихся в этой базе данных, с моими фактическими данными приложения?

Должен ли я просто ссылаться на имя текущего пользователя в моих методах действий, используя this.User.Identity.Name, чтобы использовать его в качестве ключа при хранении или получении информации о пользователе в базу данных моего приложения и из нее? Или я должен использовать this.User.Identity.UserId вместо этого? Я всегда думал, что целочисленные идентификаторы были намного быстрее искать против строки или идентификаторов базы GUID. Но основным ключом таблицы aspnet_Users является поле GUID.

Есть ли разница между this.user против this.HttpContext.User? Как насчет IPrincipal, возвращенного из этих свойств, против MembershipUser, возвращенного из Membership.GetUser(). В чем разница между ними?

Кроме того, лучше ли хранить информацию о членстве в отдельной базе данных от базы данных приложения? Или можно объединить их в одну базу данных?

Answer 1

В вашем вопросе есть несколько элементов, несколько моментов:

Обычно я использую имя пользователя, так как оно обычно более эффективно. Функция get user получает полные данные пользователя из базы данных и обновляет время последнего доступа. Принцип IP не требует этого и использует данные в памяти. Таким образом, свойство username является более быстрым и доступным. Основное предостережение заключается в том, что вы можете позволить пользователям изменять свое имя пользователя, и в этом случае идентификатор будет иметь больше смысла.

Звучит так, как будто вы принимаете во внимание наличие множества записей, связанных с пользователями. Вы правы, целые числа - самые быстрые для поиска. Если у вас большие объемы данных, вы можете сопоставить своих пользователей с целым числом, либо , продлевая членство провайдера, либо добавив таблицу сопоставления.

Что касается this.User против HttpContext.User, то никакой разницы.

Answer 2

Шаблон по умолчанию должен предоставить вам «AccountModel» в папке «Models», которая создает оболочки для некоторых из форм аутентификации / членства.Вы можете расширить это и добавить функцию для возврата текущего «HttpContext.Current.User», который является принципом IP, хранящимся в текущем HttpContext.С помощью свойства Name вы можете запросить членство по имени пользователя, чтобы получить данные о членстве (IPrincipal просто хранит самые базовые данные, такие как имя пользователя, роли и т. Д. MembershipUser имеет все остальные данные, извлеченные из базы данных).

SqlMembershipProvider довольно дурацкий imo и ограничивает, кроме как для небольших проектов ... и в то же время может быть сложным.Я использую его сейчас на сайте с более чем 2000 учетными записями, и это жалко, если вы хотите что-то настроить.Лучше всего (и в сети есть множество примеров) просто написать свой собственный, который использует формы аутентификации и избавиться от чуши Членства.У меня есть один, теперь я хотел бы написать один для начала.

Answer 3

В приложениях, где я использовал SqlMembershipProvider, я обычно сохранял его таблицы / sprocs в той же БД, что и таблицы моих приложений, а затем связывал свои таблицы приложений с пользовательскими таблицами, используя внешний ключ.Единственный раз, когда я этого не делал, было то, что одна пользовательская база данных должна была использоваться несколькими различными приложениями, у каждого из которых была своя собственная база данных приложений.