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

Здесь на помощь приходит поставщик профилей 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 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».

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

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

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

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

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

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

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

Я знаю, что этот пост публиковался давно, и контекст вопроса, вероятно, относился к 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; }
}

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