Каков наилучший способ интеграции Identity с базой данных моего приложения? - PullRequest
Новая
       8

Каков наилучший способ интеграции Identity с базой данных моего приложения?

0 голосов
/ 02 июля 2018

Я изучаю Asp.net Core и Entity Framework Core, и я создал базовое веб-приложение с базой данных с подходом кода сначала. У моего приложения есть контекст (AppContext), и для использования Identity я определил новый контекст (IdentityContext), который использует ту же базу данных. Я хочу связать каждого пользователя Identity (AppUser из IdentityContext) с одним сотрудником (из AppContext), но при попытке EF Core создайте для него новую таблицу. 

public class AppUser : IdentityUser
{
    public Employee Employee { get; set; }
}

public class Employee
{
    public long Id { get; set; }
    public string AspNetUserId { get; set; }
    public AppUser AppUser { get; set; }
}

* 1004 контекста приложения * 

protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Employee>(employee =>
        {
            employee.HasIndex(e => e.AspNetUserId);
            employee
                .HasOne(e => e.AppUser)
                .WithOne(au => au.Employee)
                .HasForeignKey<Employee>(e=>e.AspNetUserId);
        });
    }

У меня много вопросов по этому поводу:

  1. Я думаю, что нормально иметь два отдельных контекста, каждый из которых имеет только одну проблему. Это нормально? или я должен скопировать и вставить свой AppContext в IdentityContext?
  2. Как я могу сообщить моему AppContext, что он не создает новую таблицу для AppUser, и использовать таблицу, созданную IdentityContext?
  3. Есть альтернатива?

Будут оценены любые предложения или ссылки.

Спасибо.

1 Ответ

0 голосов
/ 03 июля 2018

Я думаю, что это нормально иметь два отдельных контекста, каждый контекст имеет только одна проблема. Это нормально? или я должен скопировать и вставить свой AppContext на IdentityContext

Это прекрасно. Проблема в том, что вы хотите разделить их, но НЕ позволять им иметь свои собственные проблемы.

В настоящее время вы указываете своему IdentityContext, что он должен иметь как AppUser, так и Employee, и что между ними есть связь. Тогда контекст позаботится о них обоих, если вы явно не скажете этого не делать. Но прямо сейчас вы прямо об этом говорите.

Это можно в значительной степени суммировать с этим простым правилом: разделенные контексты -> разделенные данные.

Как я могу сообщить своему AppContext, что не создает новую таблицу для AppUser, и использовать таблицу, созданную IdentityContext?

Ты действительно не должен. Не ожидайте, что Entity Framework будет обрабатывать отношения между контекстами. Это в значительной степени не будет. Если у ваших сущностей есть связь, они принадлежат к одному и тому же контексту. Вы можете видеть это как разные базы данных. Запросы между двумя различными базами данных не так гладки.

Однако вы все равно могли бы разделить их, сказав конфигурации игнорировать ссылочные объекты, как это: 

modelBuilder.Entity<AppUser>().Ignore(e => e.Employee);

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

Есть ли альтернатива?

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

Но даже я бы этого не сделал, если бы у меня было менее 15-20 сущностей. Это просто не стоит того. Преимуществ или слишком мало в таком маленьком проекте.

...