Поскольку я не смог найти пример в сети (все они показывают, как использовать пользовательский тип пользователя, а не иерархию), я попытался немного покопаться в коде.
По-видимому, с использованием проблем нетлюбой объект, унаследованный от IdentityUser (или любой другой класс, указанный в качестве пользователя в AddDefaultIdentity
.
). При попытке создать пользователя, передающего объект, который наследует от этого класса, будет создан соответствующий объект в базе данных (объектне преобразуется в UserManager.CreateAsync
, но добавляется в контекст простым добавлением в сам контекст, а не в типизированный DBSet).
Соответствующий код можно найти в исходном коде UserStore: https://github.com/aspnet/Identity/blob/master/src/EF/UserStore.cs строка 165, мы можем видеть, что существует простое
Context.Add(user);
Разрешение ядру EF создать соответствующий дискриминатор в БД.
В общем, если нет настройки аутентификации /требуется идентификация, и есть только необходимость добавить больше информации пользователю, иерархия пользователей, кажется, работает нормально и оставляет значение по умолчанию UserIdentity
Класс, объявленный в службах, не создает никаких проблем.
Я еще не проверял, не создает ли он проблемы с извлечением пользователя через UserManager, поскольку он не требуется для моего варианта использования.