Где я могу хранить дополнительные данные пользователя, используя ASP.NET MVC и SqlMembershipProvider?

Question

Итак, я создаю веб-сайт ASP.NET MVC.

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

Это где поставщик профилей вступает в игру? Как они работают? Если нет, то как еще вы сохраните и сохраните дополнительные пользовательские данные, не предоставленные в столбцах запасов таблиц MembershipProvider?

Может кто-нибудь указать мне на некоторые ресурсы о том, как это обрабатывается, как получить доступ к этим дополнительным данным пользователя, когда они мне нужны, как создать нового пользователя со всей этой информацией и т. Д.

Answer 1

Здесь заходит поставщик профилей ASP.NET. Вы можете использовать его для хранения любой информации профиля, которую вы хотите о пользователе. Все, что вам нужно сделать, это добавить нужные поля в файл web.config, Ссылка MSDN о том, как настроить поля профиля в файле web.config . Чтобы подвести итог статьи, вы просто добавляете значения имени и типа, которые хотите сохранить, в узел свойств элемента профиля. Вот пример:

<profile enabled="true">
  <properties>
    <add name="Name" />
    <group name="Address">
      <add name="Street" />
      <add name="City" />
      <add name="Zip" type="System.Int32" />
    </group>
  </properties>
</profile>

В ASP.NET Webforms Visual Studio автоматически создает строго типизированный класс профиля, который будет ссылаться на свойства пользовательского профиля. В MVC этого не происходит. Чтобы обратиться к информации профиля пользователя, просто вызовите HttpContext.Profile ["PropertyName"]. Пример:

HttpContext.Profile["Name"] = name;
HttpContext.Profile.GetProfileGroup("Address")["Zip"] = zip;

Редактировать: Как заметил Энди, использование SqlProfileProvider по умолчанию не очень хорошо, если вы хотите выполнять запросы к этим свойствам. Он совершенно прав, и, возможно, я должен был изначально отметить это ограничение. Это ограничение существует, поскольку SqlProfileProvider хранит все данные профиля в трех столбцах: PropertyNames и PropertyValuesString / PropertyValuesBinary. Все ключи хранятся в поле PropertyNames, значения, которые могут быть сохранены в виде строки, хранятся в поле PropertyValuesString и т. Д. Это означает, что выполнить запрос типа «Выбрать * из aspnet_Profile, где возраст> 10» чрезвычайно сложно. 1011 *

Answer 2

Я не совсем уверен, что есть лучшая практика, и это действительно зависит от того, как вы хотите использовать информацию.

Во-первых, вы должны признать членство, и профили это две разные вещи. Функции членства, профиля и роли ASP.NET предназначены для использования в качестве службы, обслуживающей несколько сайтов / приложений.

Если вы посмотрите на схему для этих отношений, вы заметите, что пользователи являются уникальными для системы, но пользователь может совместно использовать приложения. Это означает, что информация об их профиле также используется всеми приложениями Членство на самом деле является ассоциацией пользователя с приложением и содержит информацию об их отношении к этому конкретному приложению (пароль, пароль, вопросы и ответы и т. Д.).

Вы можете использовать провайдера профилей, как предложил Райан, но 1) эту информацию нелегко запрашивать, если вы хотите собрать метрики профиля, и 2) она распределяется среди всех потребителей услуг членства / профилей. Однако вы можете расширить его, чтобы удовлетворить ваши потребности.

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

Другой вариант заключается в том, что вы можете обращаться с ним как с услугой и отслеживать эту информацию самостоятельно, ссылаясь на собственную реализацию профиля, используя идентификатор пользователя от провайдера asp.net sql.

Есть хорошая серия (16 частей) по Членство, профили и роли на 4 парнях из Ролла, которую я бы рекомендовал прочитать, а затем, как только вы ознакомитесь со всеми движущимися части, принять обоснованное решение о том, где лучше хранить и как лучше структурировать информацию профиля, которую вы хотите создать.

Answer 3

Я знаю, что это сообщение было опубликовано в течение длительного времени, и контекст вопроса был, вероятно, для mvc2 или более ранней.

Сейчас это mvc3, и я подумал, что, возможно, другие, ищущие ответы для контекста mvc5, могут быть заинтересованы в этом решении.

В стандартном проекте mvc5, в котором включена отдельная учетная запись пользователя Следующий блок кода готов к использованию в {Project} /Models/IdentityModel.cs

// You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more.
public class ApplicationUser : IdentityUser
{
}

Просто добавьте больше свойств к этому классу, и свойства будут сохранены в базе данных. Например.

public class ApplicationUser : IdentityUser
{
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public bool Active { get; set; }
        public DateTime DateRegistered { get; set; }
}

Answer 4

Эта статья из CODE Magazine помогла мне с этой проблемой.