Я не уверен, что я должен делать это с другим MVC, но мне любопытно, какой рекомендуемый подход для добавления дополнительной информации в учетную запись пользователя ASP.NET при использовании поставщика членства? Также как связать это использование с другими объектами.
Обычно я не беспокоюсь о профилях и предпочитаю добавлять дополнительную информацию в таблицу, которая просто ссылается на USERID. Является ли это хорошим/плохим/приемлемым для подхода ASP.NET MVC или что было бы альтернативой?
Это хороший вопрос, и я боролся с ним. Я думаю, что есть три основных подхода:
Используйте поставщика профилей - это позволяет легко добавлять свойства, но громоздко выполнять такие действия, как создание таблицы пользователей, особенно если вам нужно применять фильтры/поисковые запросы. 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);
Мне было бы интересно узнать, что такое подходы других народов.
Тот факт, что вы используете MVC, не должен оказывать существенного влияния на то, как вы работаете с членством и "пользовательскими данными".
Я также обычно избегаю ASP.NET-профилей и, действительно, членство ASP.NET по умолчанию, предпочитая использовать мой собственный членский провайдер и схему "профиля", связанную с моей существующей пользовательской таблицей.
Оставьте комментарий, если вы заинтересованы в дополнительной информации о поставщиках членства в клиенте.
Мне бы хотелось увидеть гораздо больше отзывов по этой теме и тем, что делают люди. В настоящее время я использую стандартную систему членства/роли поставщика asp.net в приложении asp.net mvc и не очень люблю его.
Мой подход заключался в изменении таблицы aspnet_users и добавлении целой группы дополнительных столбцов; CompanyId, StreetAddress и т.д.
Я сохранил настройки профиля пользователей для того, как они используют веб-сайт в стандартном профиле; какую тему они используют, сколько записей отображаются в выгружаемых списках и т.д.
Как и большинство людей, получение информации в профиле и из него - это боль, и из того, что я читаю в больших системах, может стать узким местом производительности из-за сериализации.
Я склоняюсь к тому, чтобы катиться по моим таблицам, которые лучше соответствуют моей схеме приложений, внедряя пользовательский SQL-провайдер, а затем просматривают некоторые дополнительные атрибуты безопасности в asp.net mvc, если они мне нужны.