Использование ADO.NET для уровня доступа к данным в ASP.NET Core

Question

Я пытаюсь накатить высокопроизводительный DAL для моего ASP.NET Core API. Я хочу использовать ADO.NET, и у меня возникают трудности при разработке архитектуры программного обеспечения. Я ищу помощь в обсуждении хорошего подхода.

Что у меня есть

Моя кодовая база будет состоять из трех проектов

• MyApp.API
• MyApp.Repositories (слой доступа к данным)
• MyApp.Services (бизнес-логика)

Я реализую IUnitOfWork в MyApp.Repositories и создам бетон SqlUnitOfWork в MyApp.API. Startup.cs зарегистрирует IUnitOfWork до SqlUnitOfWork. Позже, когда я получу больше источников данных (Mongo и т. Д.), Я могу включить UnitOfWorkFactory.

Вопросы

1. Должен ли я регистрировать каждый репозиторий в Startup.cs или просто добавить их как свойства IUnitOfWork? Мысль здесь заключается в том, что я бы использовал Dependency Injection в своих контроллерах, сервисах и репозиториях, но мне нужно только ввести IUnitOfWork.

2. Как передать строку подключения в SqlUnitOfWork? Я знаю, что строка подключения должна оставаться в пределах MyApp.API.

Answer 1

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

Я реализовал Dapper с шаблоном хранилища. Я не использовал единицу работы, потому что решил, что это приведет к потере производительности, которую я не хотел иметь.

Вот исходный прототип, который я реализовал. https://github.com/lenardchristopher/AdoAspDotNetCoreTest

Answer 2

Я полагаю, что вы работаете с aspnet-core, таким образом, используя Entity Framework , поскольку ваш ORM будет работать в этой ситуации.

Я согласен с вами в отношении регистрации ваших репозиториев как части IUnitOfWork и последующего добавления их в качестве службы в ваш контейнер DI, который вы затем добавите в свои контроллеры.

Чтобы ответить на ваш второй вопрос, давайте предположим, что ваша реализация SqlUnitOfWork имеет конструктор, который получает экземпляр DbContext.

В ASP.NET Core DbContext добавляется в контейнер DI и, таким образом, любой другой сервис, который требует или имеет зависимость от DbContext в это конструктор, он будет автоматически разрешен DI контейнер.

Сначала не забудьте указать строку подключения в appsettings.json следующим образом.

Затем теперь давайте воспользуемся этой строкой соединения, чтобы добавить объект DbContext в наш контейнер DI и немного Дальнейшее чтение при настройке DbContext в EF Core

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<MyDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("Database")));
}

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

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IUnitOfWork, SqlUnitOfWork>();
}

Надеюсь, это ответит на ваши вопросы. Если нет, дайте мне знать.