Помогите мне решить, использовать ли ASP.NET по умолчанию поставщики членства / ролей или написать пользовательских

Question

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

У меня уже есть схема базы данных, с которой я буду работать, однако она не установлена ​​в камне; Я могу внести изменения в него, если это необходимо. В этой схеме уже есть таблица Users, использующая целое число в качестве первичного ключа. Эта таблица также содержит другую информацию, такую ​​как имя и фамилия. У меня также есть внешние ключи, основанные на UserId для других таблиц, таких как Phone и Address. Ниже я опишу некоторые плюсы и минусы, которые приходят на ум.

Поставщик по умолчанию

Плюсы

• Меньше кода.
• Возможность использования всех связанных серверных элементов управления, таких как Логин, ChangePassword.

Против

• Некоторые элементы управления могут быть бесполезны для меня из коробки. Например, CreateUserWizard, мне нужно будет захватить другую информацию во время создания пользователя, такую ​​как информация о телефоне и адресе для связанных таблиц. Не уверен, что это делает этот контроль бесполезным для меня.
• Мне нужно будет создать внешние ключи в связанных таблицах (Телефон, Адрес) для UserId, который является GUID в поставщике по умолчанию.
• Если я создаю эти ограничения внешнего ключа и не использую каскадное удаление; Мне нужно будет также удалить связанные строки в таблицах внешнего ключа. Потенциально необходимо использовать что-то вроде объекта TransactionScope, чтобы убедиться, что все это атомарная операция.

Пользовательский провайдер

Плюсы

• Возможность использовать существующие таблицы схем.
• Проще извлечь аутентификацию / авторизацию в службу по линии.

Против

• Должен сам обеспечивать реализацию для большинства / всего.
• Чтобы использовать любой из элементов управления, я должен предоставить их необходимую реализацию в провайдере.

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

Спасибо.

Answer 1

Мне недавно пришлось сделать такой же выбор, и я решил заняться созданием собственного провайдера.

Моя самая большая причина сделать это сводилась к схеме БД по умолчанию.Все объекты db по умолчанию создаются в схеме dbo и имеют префикс «aspnet_» или «vw_aspnet» и т. Д. Для меня это был настоящий поворот.Если вы еще не видели их, запустите aspnet_regsql.exe, чтобы создать их.

Кроме того, Стивен Сандерсон говорит об этом в Pro ASP.NET MVC 2 Framework:

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

В целом, стоит следовать API из-за четкого разделенияпроблем, повторного использования в проектах и ​​интеграции с остальной частью ASP.NET, но вы будете использовать встроенные поставщики хранилища SQL только для небольших или одноразовых проектов.

У меня нетЯ прошел весь процесс создания пользовательских провайдеров (я частично реализовал это, когда играл с хранилищем Azure Table), но я планирую использовать этих провайдеров в нескольких проектах в будущем, поэтому я чувствую, что усилия будут хорошимистоит того.

Answer 2

Лично я использую SqlMembershipProvider в качестве автономного объекта, в то время как остальная часть моей базы данных находится в Oracle. Я никогда не смотрю на базу данных, поэтому имена и GUID меня не беспокоят (вне поля зрения, из головы). Это просто работает из коробки, и это здорово!

В моем сценарии у меня есть пользовательская таблица в базе данных Oracle, которую я вставляю / удаляю при создании / удалении пользователей (без GUID). Я считаю базу данных членства «основной» записью, а таблицу Oracle - в основном для ссылочной целостности вспомогательных таблиц. Это не сделано в официальной транзакции, но я использую try / catch, чтобы синхронизировать их достаточно хорошо.

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

Управление неплохое. Многие из них поддерживают шаблоны, так что вы можете добавить к ним свои собственные элементы управления и иметь множество событий, чтобы подключиться к ним. Не бойтесь бросать свои собственные элементы управления, но сначала дайте шанс элементам управления по умолчанию. Простота использования API членства действительно облегчает создание этих элементов управления.

Answer 3

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

Answer 4

Лично я бы пошел с тем, что обеспечивает структура.В этом случае нет оснований использовать вашу собственную аутентификацию.

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