Сохранять настройки пользователя в таблице ASP.NET Core Identity AspNetUsers или нет
Я настраиваю веб-приложение с использованием ASP.NET Core с аутентификацией через Identity Framework. Быстрый вопрос. Я храню все виды данных о пользователе, такие как его адрес, настройки учетной записи, статус подписки и срок действия и т. д. Мне лучше хранить все это в таблице AspNetUsers, создав класс ApplicationUser, наследующий IdentityUser, или я должен сохранить эту таблицу для входа в систему/информации о безопасности и создать другую таблицу для хранения данных, относящихся только к моему приложению, и иметь отношения 1-к-1 между двумя таблицами?
Ответы 1
Всегда отдельный стол/класс.
Сложность растет вместе с приложением. Стол станет слишком большим, и вы потратите время на то, чтобы отойти от него. У нас есть подобное в нашем устаревшем приложении с организацией, которая выросла до 70+ столбцов. Я слышал истории в Твиттере о людях с похожим опытом.
Также наряду с этим вы можете подумать о единой ответственности. Учитывая одну причину для изменения - или больше, чтобы дядя Бобс обновил определение "A module should be responsible to one, and only one, actor".
В итоге у вас могут быть настройки для module — и чем больше вы добавите, тем больше будет их количество. Конечно, просто оставьте это на потом, чтобы изменить ситуацию, но этого никогда не происходит.
Для меня Айдентика — это собственная система. Не ваша система. Он обеспечивает механизм аутентификации. Для этого он использует большинство столбцов в способности или полей в пользовательском классе.
Ваши настройки касаются вашего приложения - это ваш домен. Если вы замените Identity, вы можете заменить эту пользовательскую таблицу/пользовательский класс. Тогда где ваши настройки в конечном итоге?
Когда я перемещаю поля из ApplicationUser в Customer, я понимаю еще кое-что: не все пользователи являются клиентами! Моей учетной записи администратора не нужна информация о клиенте.
Также следует учитывать GDPR. Мне нравится хранить предоставленные пользователем данные отдельно от данных о пользователе, собранных с помощью других средств. Таким образом, когда/если ваш пользователь решит удалить всю свою информацию, он удалит только ту информацию, которую предоставил.