Я работаю в небольшой команде разработчиков, и нет единого мнения о наилучшем подходе к решению ряда основных задач, одной из которых является членство в организации.Теперь я не могу быть уверен в том, что это связано с отсутствием доступа к альтернативным способам мышления или проектам, достаточным для проведения значительного расследования.
Я был разработчиком .net net в течение нескольких лет (и до этого php и asp classic), и обычно при разработке приложений я избегаю использовать встроенный .net SqlMembershipProvider, прежде всего потому, что ончасто кажется слишком сложным для моих нужд, и, во-вторых, потому что я могу только представить, что такая сложная модель данных, скорее всего, приведет к снижению производительности.
Обычно я использую пользовательский поставщик членства и ролей, работающий по довольно простой схеме типа user -> user roles <- roles.Я поддерживаю стандартные функции поставщика членства, такие как восстановление учетной записи, детали профиля, неудачная блокировка учетной записи, секретные вопросы и т. Д., В зависимости от потребностей соответствующего приложения, такого как защищенное приложение AD, имеет несколько дополнительных функций, обычно общедоступное приложение будет иметьторговый центр.Это также означает, что при появлении любых задач, требующих сохранения хранимых процедур для просмотра пользовательских данных, их легко писать и выполнять очень хорошо.Простые команды SQL, хорошая индексация и простая модель данных, приводящая к высокопроизводительному, масштабируемому решению, которое должно быть изменено. Я имею полный контроль над изменениями по мере необходимости, что я считаю бесценным.
Исходя из вашего опыта, вы бы сказали этоэто устаревший подход?Были ли у вас проблемы с масштабируемостью со встроенным провайдером?Какой подход вы обычно используете и в каких сценариях?
Спасибо