Entity Framework и шаблон репозитория ASP. NET Core UOW.

Question

У меня есть ASP. NET Базовое приложение, которое структурировано в три уровня:

• Уровень доступа к данным (Entity Framework)
• Бизнес-логика c layer (Единица работы, шаблон репозитория)
• ASP. NET MVC веб-приложение

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

Для начала я использовал сначала подход базы данных для инициализации моей структуры сущностей. Здесь я использовал метод scaffolding, и он работал просто отлично.

Однако я заметил, что app.config больше не присутствует ни в одной из моих библиотек и что моя строка подключения была перемещена в метод в моем исходном коде, то есть:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
//connection stuff here
}

По сравнению чтобы использовать EF в. net Framework, я обычно использовал бы строку подключения, которая находится в моем app.config, то есть:

public EFClass(string connString)
        : base(connString)
    {

Это больше не может быть сделано, и я вынужден использовать appsettings. json в моем MVC веб-приложении, которое как бы портит идею слабой связи моего приложения.

• Оптимально, как мне добраться до моей строки подключения на уровне доступа к данным, когда у меня больше нет app.config?

Кроме того, я читал в нескольких местах, что шаблон хранилища UOW является своего рода избыточным, как в DbContext. NET Основные приложения также могут использоваться для DI? Должен ли я избавиться от своего UOW и просто вставить свой DbContext прямо в мои репозитории?

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

Answer 1

EF уже реализует шаблон UoW - DbSet s - это ваши репозитории, а DbContext - ваша единица работы. Фильтры и логи c, которые вы будете sh применять для вставки / обновления / удаления указанных c сущностей, можно настроить в вашей реализации DbContext (так или иначе). Если я не думаю, что могу доверять разработчикам с использованием DbContext напрямую, я предпочитаю создавать API.

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

Пример (из this ):

public void ConfigureServices(IServiceCollection services)
{
    ...

    // this method allows you to configure you DbContext options
    services.AddDbContext<YourDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

    ...
}

Answer 2

Интерфейс и класс вашего класса UoW должны получить строку подключения в конструкторе. В методе ConfigureServices внутри вашего класса Startup вы получаете строку подключения настроек приложения. json.

 public void ConfigureServices(IServiceCollection services)
 {
     services.AddScoped<IUnitOfWork>(x => new UnitOfWork(strConnection));
 }