ASP Core. Лучшие практики для нескольких личностей - PullRequest
Новая
       12

ASP Core. Лучшие практики для нескольких личностей

0 голосов
/ 09 ноября 2018

env: Asp Core, Entity-framework

В моей системе у меня есть два типа 

[Table("User")]
ApplicationUser : IdentityUser<Guid>

[Table("Customer")]
Customer : IdentityUser<Guid>

Обе сущности (Customer и User) имеют много разных полей, что делает использование только одной таблицы в базе данных некорректным. И обе сущности должны иметь возможность сделать вход.
Как я обнаружил, ASP Net может иметь только одну настройку идентичности.

Вопрос: Каков наилучший способ или лучшие практики для того, чтобы этот материал работал?

1 Ответ

0 голосов
/ 10 ноября 2018

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

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

Если вам необходимо представлять пользователя приложения с другой точки зрения (в качестве вашего сотрудника или в качестве вашего клиента, может быть, в качестве гостевой записи и т. Д.), То лучше создать другую таблицу (Сотрудники, Клиенты, Гости и т. Д.) Для это в другом DbContext (не в контексте идентичности). Это даст вам возможность не смешивать свои концептуальные границы. Кто знает, может быть, в какой-то момент вы решите создать отдельные микросервисы для каждого граничного контекста, и удостоверение будет служить им всем как еще один микросервис.

Если вы сейчас спрашиваете себя, как организовать такое параллельное хранение интерпретаций одного и того же пользователя приложения, то есть разные подходы. Но например:

  • Когда пользователь регистрируется, вы создаете для него личность
  • Когда он вошел в систему, он использует свои идентификационные данные для аутентификации
  • Но когда он создает свой первый заказ, вы создаете для него запись Клиента, у которой тот же Id, что и его Идентичность, или внешний ключ к Идентичности, или ... все остальное зависит от ваших потребностей и бизнес-логики.
...