Куда поместить строку подключения при перемещении кода базы данных в отдельную сборку

Строка подключения должна быть настроена в том же проекте, где службы подключаются к DbContext, поэтому вы можете оставить appsettings.json как есть.

Именно проект настройки (тот, который настраивает все зависимости) устанавливает подключение к БД, а инструменту миграции EF требуется подключение для отслеживания и применения изменений. Любая сборка может использоваться для хранения миграций, но инструмент EF необходимо вызывать для проекта с фактическим подключением.

EF Core использует внедрение зависимостей для настройки служб для среды выполнения, включая настройку строки подключения для любой БД. Контроль над тем, как классы БД взаимодействуют со своей средой, предоставляется приложению, которое его запускает, что позволяет использовать один и тот же код БД в нескольких экземплярах, состояниях и даже провайдерах. EF Core использует текущее состояние и поставщика базы данных, в которой он развернут, для определения изменений и формирования шаблонов, поэтому он может создавать миграции только с настроенным экземпляром DbContext, подключенным к базе данных (обычно это экземпляр разработки).

Если решение состоит из нескольких зависимых служб с общей моделью данных, которым потребуются одни и те же миграции, только один из проектов в решении должен отвечать за управление состоянием БД. Какой бы проект ни был выбран, он должен создать DBContext с допустимым соединением при запуске, чтобы инструменты EF работали. ASP.NET Core использует пакет Microsoft.Extensions.Configuration и метод UseStartup для упрощения настройки. Это может быть ваш существующий проект пользовательского интерфейса, который будет считывать строку подключения из существующих настроек и передавать ее в ваш CustomDbContext при запуске. Интерфейс командной строки EF Tools будет использовать профиль по умолчанию (зеленая стрелка запуска), чтобы получить настройки от launchSettings.json и appSettings.json для подключения к базе данных. Конфигурация должна присутствовать в каждой среде, в которой выполняется развертывание, чтобы миграции можно было запускать из одного и того же проекта настройки и применять по мере необходимости.

Вы можете отказаться от ASP.NET и создать пользовательский класс запуска в вашем пакете данных, который запускается для применения миграций, но это требует много дополнительной работы для того, что уже есть в коробке. В классе DbContext есть метод OnConfiguring, который можно использовать для установки соединения. Размещение конфигурации внутри ограничений кода, в которых может работать программное обеспечение, поэтому оно все равно должно быть устанавливается извне.

На DbContext можно ссылаться из другого пакета:

DbContext и модели могут быть определены в отдельном «чистом» проекте, а затем указаны в Startup следующим образом:

    using mysolution.Data.CustomDbContext;
...
     services.AddDbContext<CustomDbContext>(options =>
                    options.UseSqlServer(
                        Configuration.GetConnectionString("defaultConnection")));

Настройте запуск DbContext и место для хранения миграций:

Сложность заключается в применении миграций, если вы их используете. Если ваша сборка Razor называлась 'mysolution_UI', а проект данных — 'mysolution_Data'. Переместите Data, Models, Migrations в mysolution_Data и добавьте это в запуск в проекте mysolution_UI:

    services.AddDbContext<CustomDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("defaultConnection")
            , b => b.MigrationsAssembly("mysolution_Data")));

Затем при добавлении или развертывании пакета миграцию следует вызывать из проекта 'mysolution_UI'.

   Add-Migration NewMigration -Project mysolution_UI

Это позволяет нескольким проектам использовать пакет данных для объектов, подключенных к одной и той же базе данных, но только один из них отвечает за поддержку миграции.