Пользовательская логика скаффолдинга для базы данных в первую очередь

Question

Я новичок в Entity Framework Core, так как сейчас я перехожу с EF6. Мы используем базу данных первой модели.

Я создал библиотеку классов .Net Standard, в которую импортировал EF Core и использовал команду scaffolding в VS для импорта одной из моих таблиц в качестве теста - что сработало.

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

Я настроил различные параметры подключения, что-то вроде пункта 2 в ответе в этом посте Использование миграции Entity Framework Core для проекта библиотеки классов , чтобы мы могли поддерживать подключения к различным базам данных.

Теперь я хочу добавить остальные таблицы. Я видел упоминания о миграциях, но, похоже, это касается моделей с первым кодом.

Затем я попытался использовать команду "-Force" на скаффолдинге, которая импортировала дополнительную таблицу, но я потерял поддержку нескольких баз данных.

В EF6 у меня была эта логика в файле Context.tt, поэтому, когда я получал обновления из базы данных, она сохраняла пользовательские параметры подключения, которые у меня были.

Есть ли способ воспроизвести это в EF Core или мне чего-то не хватает?

Кроме того, для чего-то столь же простого, как новый столбец в таблице, должен ли я по-прежнему выполнять ту же команду?

Заранее спасибо,

David

* ОБНОВЛЕНО *

В итоге я использовал EF Core Power Tools, который является отличным пакетом и позволяет полностью контролировать модель, во многом как файл context.tt, который использовался.

Для тех, кто смотрит в будущее, я разработал и использовал шаблоны Handlebars в EF Core Power Tools. Я передаю 3 строки подключения, которые я использую при запуске приложения, и затем могу установить необязательные логические значения, чтобы указать, какое соединение использовать - перечисление может быть более элегантным для любого, кто начинает снова, но это облегчает миграцию для нас. В DbConstructor.hbs я обновил его до:

{{spaces 8}}public {{class}}(bool ReadOnlyDatabase = false, bool ReportsDatabase = false) : base()
{{spaces 8}}{ 
            if (ReadOnlyDatabase)
                _connectionString = ReadOnlyContext;
            else if (ReportsDatabase)
                _connectionString = ReportsContext;
            else
                _connectionString = ReadWriteContext;
{{spaces 7}} }

Файл DbContext.hbs:

{{> dbimports}}

namespace {{namespace}}
{
    public partial class {{class}} : DbContext
    {
        public static string ReadWriteContext = "";
        public static string ReadOnlyContext = "";
        public static string ReportsContext = "";

        private readonly string _connectionString;
{{{> dbsets}}}
{{#if entity-type-errors}}
{{#each entity-type-errors}}
{{spaces 8}}{{{entity-type-error}}}
{{/each}}

{{/if}}

{{{> dbconstructor}}}

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlServer(_connectionString);
        }
{{{on-model-creating}}}
    }
}

Answer 1

Вам нужно опубликовать больше своего кода, чтобы мы могли видеть, что происходит. Похоже, это звучит так, будто вы настраиваете сгенерированный класс контекста. Он будет перезаписываться с каждой операцией скаффолда, и, как вы заметили, существует поддержка миграции для управления обновлениями схемы БД в результате изменений модели. То есть сначала для кода.

Кажется, что подход db first scaffold написан с расчетом на то, что scaffold будет выполнен один раз, и после этого модели и контексты будут обновляться вручную. У нас есть рабочий процесс, который включает в себя перестройку DbContext в ответ на обновления схемы БД и, следовательно, выполнение трех действий:

• создает локальный хост или базу данных SSPI, чтобы во встроенной строке соединения не было паролей значения.
• допускает раздражающее предупреждение на CI / CD о строке подключения, которую скаффолдер генерирует каждый раз, когда невозможно отключить.
• мы используем методы расширения для добавления функциональности в DbContext при необходимости, поэтому нам никогда не нужно изменять сгенерированный код.

Теперь я бы не предлагал методы расширения для инициализации различных строк подключения.

Те, кто, я уверен, уже пришли из config, но если нет, то вы делаете консольное, а не базовое приложение asp.net, которое делает создание DbContexts на основе конфигурации действительно простым, я бы действительно посоветовал узнать, как использовать, по крайней мере, Microsoft. Расширения. Конфигурация для настройки ваших экземпляров DbContext из appSettings.

Я не могу поделиться примером кода инициализации DBContext с DbOptionsBuilder напрямую, потому что мой виновный секрет заключается в том, что я всегда получаю DI в Asp.net Core, чтобы сделать это для меня.

Answer 2

Предоставить конструктору DbContextOptions:

    public MetadataContext(DbContextOptions<MetadataContext> options)
        : base(options)
    {
    }

Может быть, EF Core Power Tools могут вам помочь?(Я автор)