Использует ли большинство пользователей .NET SqlMembershipProvider, SqlRoleProvider и SqlProfileProvider?

Question

Использует ли большинство людей .NET SqlMembershipProvider, SqlRoleProvider и SqlProfileProvider при разработке сайта с возможностями членства?

Или многие люди делают своих собственных провайдеров, или даже полностью свои собственные системы членства?

Каковы ограничения провайдеров SQL, которые заставляют вас работать самостоятельно?

Легко ли расширить возможности SQL-провайдеров для обеспечения дополнительной функциональности?

Для справки
Согласно блогу Скотта Гу , Microsoft предоставляет исходный код для SqlMembershipProvider , чтобы вы могли настроить его, а не начинать с нуля. Просто к вашему сведению.

Answer 1

Мы используем все, кроме провайдера профилей. Поставщик профилей полностью основан на тексте и выполняет полнотекстовый поиск - это становится чрезвычайно медленным по мере увеличения вашей пользовательской базы. Мы нашли, что это намного лучшее решение для "роли нашего" профиля в базе данных api членства, которая привязана к идентификатору пользователя в членстве.

Answer 2

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

Answer 3

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

Answer 4

Обычно я использую провайдеров, которые поставляются «из коробки», главная проблема, с которой я сталкиваюсь, это запросы по атрибутам профиля у пользователей. Например, поиск всех пользователей с атрибутом профиля Car, который равен true. Это связано с тем, как они хранятся в базовой структуре.

Answer 5

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

Я абстрагировал слои, чтобы они работали на логическом уровне, и имел слой DAL, который использовал бит data.common.dbprovider, поэтому он был достаточно универсальным.

Answer 6

Если вам нужна только базовая поддержка пользователей (роли, профили и т. Д.), То поставщики по умолчанию будут работать отлично.

Если вам нужна более настраиваемая поддержка (хранение данных в базе данных, не поддерживаемой провайдерами по умолчанию [например, Oracle], провайдер в базе данных, которая уже существует, сильно настроенная схема), тогда вам следует свернуть своих собственных провайдеров.

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

Answer 7

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