Связывание дополнительной информации с членством ASP.NET MVC

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

Обычно я не беспокоюсь о профилях и предпочитаю добавлять дополнительную информацию в таблицу, которая просто ссылается на USERID. Является ли это хорошим/плохим/приемлемым для подхода ASP.NET MVC или что было бы альтернативой?

Ответы

Ответ 1

Это хороший вопрос, и я боролся с ним. Я думаю, что есть три основных подхода:

  • Используйте поставщика профилей - это позволяет легко добавлять свойства, но громоздко выполнять такие действия, как создание таблицы пользователей, особенно если вам нужно применять фильтры/поисковые запросы. API просто не сокращает его.

  • Добавить новую таблицу (или расширить существующую таблицу), а затем присоединиться к ней. Затем вам нужно будет написать свои собственные методы для возврата пользовательских данных.

  • Напишите свой собственный членский провайдер, который расширяет класс MembershipProvider.

В моем последнем проекте я использовал последний подход - я написал очень сложный SQL-провайдер, который реализовал только основные требования, необходимые для создания пользователей, проверки подлинности и изменения паролей. Для остальных виртуальных методов я просто выбрал NotImplementedException.

Затем я добавил новый класс, который добавил дополнительные свойства, которые мне нужны, и сделал его таким, чтобы его можно было создать, передав стандартный MembershipUser. Что-то вроде этого:

public static CustomMember GetMember(MembershipUser user)
{
    // Get your custom member
}

Таким образом, вы можете использовать стандартный MemberhipUser для большинства вещей, но если вам нужно получить более подробную информацию о текущем пользователе, вы делаете такие вещи следующим образом:

MembershipUser user = Membership.GetUser();
CustomMember member = CustomMember.GetMember(user);

Мне было бы интересно узнать, что такое подходы других народов.

Ответ 2

Тот факт, что вы используете MVC, не должен оказывать существенного влияния на то, как вы работаете с членством и "пользовательскими данными".

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

Оставьте комментарий, если вы заинтересованы в дополнительной информации о поставщиках членства в клиенте.

Ответ 3

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

Мой подход заключался в изменении таблицы aspnet_users и добавлении целой группы дополнительных столбцов; CompanyId, StreetAddress и т.д.

Я сохранил настройки профиля пользователей для того, как они используют веб-сайт в стандартном профиле; какую тему они используют, сколько записей отображаются в выгружаемых списках и т.д.

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

Я склоняюсь к тому, чтобы катиться по моим таблицам, которые лучше соответствуют моей схеме приложений, внедряя пользовательский SQL-провайдер, а затем просматривают некоторые дополнительные атрибуты безопасности в asp.net mvc, если они мне нужны.