Использует ли большинство пользователей.NET SqlMembershipProvider, SqlRoleProvider и SqlProfileProvider?
Использует ли большинство людей.NET SqlMembershipProvider, SqlRoleProvider и SqlProfileProvider при разработке сайта с возможностями членства?
Или многие люди делают своих собственных провайдеров, или даже свои собственные системы членства полностью?
Каковы ограничения поставщиков SQL, которые заставили бы вас делать свои собственные?
Легко ли расширить возможности SQL-провайдеров для обеспечения дополнительной функциональности?
Для справки
Согласно блогу Скотта Гу, Microsoft предоставляет исходный код для SqlMembershipProvider, чтобы вы могли настроить его, а не начинать с нуля. Просто к вашему сведению.
7 ответов
Мы используем все, кроме поставщика профилей. Поставщик профилей полностью основан на тексте и выполняет полнотекстовый поиск - это становится чрезвычайно медленным по мере увеличения вашей пользовательской базы. Мы нашли, что это намного лучшее решение для "роли нашего собственного" раздела профиля базы данных API членства, который связан с идентификатором пользователя в членстве.
Я свернул свой собственный MembershipProvider классы с использованием производных MembershipUser типы для переноса пользовательской схемы пользователя, поэтому свойства стиля профиля теперь доступны повсеместно как часть производного пользователя с помощью приведения.
Обычно я использую провайдеров, которые поставляются "из коробки", основная проблема, которую я имею, - это запросы к атрибутам профиля у пользователей. Например, найти всех пользователей с атрибутом профиля Car, который равен true. Это связано с тем, как они хранятся в базовой структуре.
Я использовал SqlMembership и раньше, и это неплохо, если вам не нужно что-то нестандартное. Я помню, что мне нужно было что-то вроде имени и фамилии, и я понял, что для этого нет полей. В итоге вместо расширения я использовал поле "Комментарий" провайдера и добавил туда информацию об имени. Это, вероятно, плохая практика / ленивый / хакерский путь, но у меня получилось в трудной ситуации..
Теоретически они звучат хорошо, но это не шанс, если вы проведете какое-либо модульное тестирование, не создавая много абстрактных оболочек.
Я использовал как пользовательские классы, так и встроенные. Когда вам нужно получить доступ к другой базе данных или схеме или вам нужна дополнительная информация.
Я абстрагировал слои, чтобы он работал на логическом уровне и имел уровень DAL, который использовал бит data.common.dbprovider, поэтому он был достаточно универсальным.
Если вам нужна только базовая поддержка пользователей (роли, профили и т. Д.), То поставщики по умолчанию будут работать отлично.
Если вам нужна более настраиваемая поддержка (хранение данных в базе данных, не поддерживаемой провайдерами по умолчанию [например, Oracle], провайдер в базе данных, которая уже существует, сильно настроенная схема), тогда вам следует свернуть своих собственных провайдеров.
Что касается меня, мой текущий сайт нуждался только в базовой поддержке ролей (и минимальной поддержке профилей), поэтому я выбрал поставщиков по умолчанию.