Переопределение поставщика членства ASP.NET

Question

Я пытаюсь понять смысл наследования поставщика членства в пользовательском классе и переопределить его для реализации собственного настраиваемого поставщика.

В чем преимущество этого, когда поставщик членства сосет в первую очередь!

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

Answer 1

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

Преимущество его использования состоит в том, что он прост, достаточно хорошо документирован и содержит множество примеров в Интернете.

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

Answer 2

Вы переопределяете поставщика членства, чтобы вы могли использовать API членства с ним.Это полезно для многих целей.Например, если вы пытаетесь интегрировать многие сторонние веб-форумы в свое приложение, они требуют использования API членства.

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

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

Answer 3

Основным преимуществом является то, что поставщик членства просто работает со всеми "готовыми" функциями asp.net. Такие вещи, как Аутентификация с помощью форм, SiteMapProviders и т. Д., Предназначены для хорошей работы с поставщиком членства asp.net, поэтому зачастую ключом является не сам поставщик, а то, что он зависит от поставщика и стоит того, чтобы его повторно реализовать.

Сказав это, это не означает, что поставщик членства подойдет для вашей ситуации, так как вы можете не использовать какие-либо компоненты, которые зависят от него, и в этом случае он не делает много смысла в ее реализации, и поэтому вам было бы гораздо лучше написать собственную модель членства, соответствующую вашим потребностям.