Блог

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

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

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

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

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

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

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

Что касается этого.Пользователь vs HttpContext.User, никакой разницы.

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

SqlMembershipProvider довольно дерьмовый imo и ограничивает возможности, отличные от небольших проектов…и в то же время это довольно сложно. Сейчас я использую его на сайте с более чем 2000 учетными записями, и это pita, если вы хотите что-то настроить. Лучше (и в сети есть много примеров) просто написать свой собственный, который использует formsauthentication и избавиться от ненужного членства. Теперь у меня есть один, и я хотел бы написать его для начала.

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