Способы управления конфигурацией в проекте с несколькими уровнями - PullRequest
Новая
       12

Способы управления конфигурацией в проекте с несколькими уровнями

0 голосов
/ 07 июня 2018

Шаблон проекта ASP.NET Core поставляется с appsettings.json и appsettings.Development.json и добавляется по умолчанию в CreateDefaultBuilder .

Поскольку проект с DbContext отделен от моего проекта ASP.NET Core (MyProject.Data), мне необходимо реализовать IDesignTimeDbContextFactory для моего контекста для таких команд, как Add-Migration и Update-Databaseработать.Я не хочу жестко кодировать строку подключения для моего IDesignTimeDbContextFactory, но повторно использовать конфигурацию в обоих проектах.

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

  • Реализация IDesignTimeDbContextFactory в моем проекте ASP.NET Core (UI layer).
  • Реализация IDesignTimeDbContextFactory в моем MyProject.Data проекте и перемещение appsettings.jsonв какой-либо корневой каталог или в каталог configuration (расположенный в корневом каталоге), общий для проектов.
  • Создайте отдельный файл конфигурации для базы данных, например database.json, поместите его рядом с моим .sln файлом.

Как мне поделиться этим?

РЕДАКТИРОВАТЬ:

Здесь есть похожий вопрос и ответ: ConnectionString из appsettings.json на уровне данных с Entity Framework Core , но этоне отвечает на мой вопрос.Это вообще ничего не говорит об уровне данных.Я не хочу повторно использовать логику для добавления контекста БД. Я хочу повторно использовать строку подключения в двух проектах , чтобы избежать дублирования строк подключения.

Ответы [ 2 ]

0 голосов
/ 11 июня 2018

Мой подход / мнение к этой теме:

Используйте строку подключения в каждом приложении верхнего уровня, используя ваш DbContext, такой как API / Backend / Frontend, потому что они могут работать на разных серверах.Поэтому у них должен быть свой собственный файл настроек.

Для обработки миграций из библиотеки без строки подключения вы можете использовать следующий подход:

cd /projectWithContextImpl

dotnet ef -s "../projectWithConnString/" migrations list -c NameOfContext

Надеюсь, это несколько ответит на ваш вопрос.

0 голосов
/ 11 июня 2018

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

В следующем примере информация строки подключения хранится во внешнем datasettings.json file 

{
  "ConnectionStrings": {
    "DefaultConnection": "connection string here"
  }
}

Простой пример автономного расширения установки для слоя может выглядеть как 

public static class MyServiceCollectionExtensions {
    public static IServiceCollection AddMyDataLayer(this IServiceCollection services, string name = "DefaultConnection") {
        var builder = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("datasettings.json"); //<<< just an example

        var connectionStringConfig = builder.Build();

        services
            .AddEntityFrameworkSqlServer()
            .AddDbContext<YourDbContext>((serviceProvider, options) =>
                options
                    .UseSqlServer(connectionStringConfig.GetConnectionString(name))
            );
         return services;
    }
}

И добавлено в Запуск 

using my.data.layer;

//...

public void ConfigureServices(IServiceCollection services) {

    //...

    services.AddMyDataLayer();

    //...
}

Уровень данных в этом случае управляет своей собственной конфигурацией.Его файл настроек является внешним по отношению к настройкам приложения.

Существует пространство для расширения, так как дополнительными опциями можно управлять и локально, и оно хорошо работает, например, для плагинов «под ключ».

Характер модуля Конфигурация в ASP.NET Core допускает такие гибкие возможности.

...