Принятие таблиц "aspnet_ ..." из ASP.NET MVC

Question

Я только начинаю новый проект на ASP.NET MVC, и это будет первый проект, использующий эту технологию. Когда я создавал свой новый проект в Visual Studio 2010, он создал для моего сервера sql несколько таблиц с префиксом aspnet_. Часть из них имеет дело со встроенными учетными записями пользователей и поддержкой разрешений.

Теперь я хочу сохранить определенную информацию о моих пользователях. Мой вопрос: «Является ли хорошей практикой изменение структуры этих таблиц aspnet_ для удовлетворения моих потребностей в информации учетной записи пользователя?».

И, как я полагаю, ответ "Нет" (Почему именно?), Я намерен создать свою собственную таблицу «Пользователи». Что является хорошим подходом для соединения записей из таблицы aspnet_Users и моей собственной пользовательской таблицы Users.

Я хочу, чтобы отношение было 1: 1, а дизайн в базе данных был максимально прозрачным в моем коде на c # (я использую linq to sql, если это важно). Кроме того, я не хочу копировать имена пользователей и пароли из таблиц aspnet_ в мою таблицу и поддерживать данные.

Я собираюсь использовать вид, чтобы присоединиться к ним. Это хорошая идея?

Заранее спасибо!

РЕДАКТИРОВАТЬ: Из ответа, я вижу, что я, возможно, не достаточно ясно, что я хочу. Вопрос не в том, ЕСЛИ использовать поставщика asp.net по умолчанию, а в том, как его адаптировать к моим потребностям.

Answer 1

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

Answer 2

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

Недавно я столкнулся с тем же сценарием, и в итоге отказался от функции членства и развернул свое собственное решение по БД в тандеме с библиотекой DotNetOpenAuth.

Answer 3

Использование системы членства в asp.net имеет свои преимущества и недостатки. Это легко начать, потому что вам не нужно беспокоиться о проверке, регистрации пользователя, сбросе паролей. (Будьте осторожны, если вы планируете изменять структуры таблиц, вам придется изменить их в сгенерированных процедурах представлений / хранения

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

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