ASP.NET членство и разделение ролей

Question

У меня есть проект ASP.NET, в котором я хочу сохранить членство (поставщик SQL) в отдельной базе данных, и роли / профили будут для каждого приложения.

Вопрос

Что такое КЛЮЧ, который связан между базой данных Членства и базой данных Ролей / Профилей? Это идентификатор пользователя или имя пользователя?

Я открыл таблицы в отдельном модуле развертывания и заметил, что идентификатор пользователя в базе данных Membership отличается от идентификатора в базе данных ролей приложения.

Answer 1

Если я правильно прочитал ваш вопрос, вы хотите сохранить членство в одном экземпляре базы данных и роли в другом.

Это приемлемо и возможно, просто предоставляя различные строки подключения. Вам не нужно не реализовывать пользовательский провайдер.

Понимание того факта, что роли и членство являются действительно отдельными проблемами, за исключением незначительного кровотечения, вызванного методом MembershipProvider.DeleteUser, и могут работать изолированно.

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

Общим значением, используемым в стеке провайдера, является поле username, которое, хотя и является уникальным для приложения, не является ключом.

Таким образом, если вам известно, что вы должны вручную удалять записи ролей при вызове Membership.DeleteUser, вы можете просто использовать две базы данных, пользовательская реализация не требуется.

Удачи

Answer 2

Лучшее, что вы можете сделать в этом случае, - это реализовать свой собственный (пользовательский) поставщик MemberShip и Role.Отношение между членством и ролями определяется вами, и для этого обычно используется имя пользователя.

Примечание к ответам Поэта:

Возможно, я не должен был упоминать«лучшее решение», но, по моему мнению, членство в AspNet по умолчанию и поставщик ролей сопровождает таблицы Aspnet, которые создаются с помощью команды aspnet -regsql.Если членство в Microsoft и поставщик ролей не удовлетворяют вашим потребностям, вам следует создать свои собственные.Если вы создадите своего собственного поставщика членства и роли, другим разработчикам будет ясно, что они имеют дело с реализацией поставщика, которая работает или структурирована по-другому.

Мой вывод заключается в том, что мое решение, возможно, не«лучшее решение», но больше рекомендация.Другое дело, что провайдеры ASP.NET в любом случае не являются примером хорошего дизайна программного обеспечения.Мы все еще используем его из-за их совместимости с другими элементами управления.Ваше решение в порядке, но мое будет так же хорошо, и это до мр.Саиф выберет решение, которое лучше всего подходит для его приложения.

Как отмечает Microsoft:

Существует две основные причины создания настраиваемого поставщика членства.

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

•Вам необходимо управлять информацией о членстве, используя схему базы данных

, которая отличается от схемы базы данных, используемой поставщиками, поставляемыми с .NET Framework