在ASP.NET Core中使用ADO.NET作为数据访问层

Question

我正在尝试为我的ASP.NET Core API推出高性能DAL。 我想使用ADO.NET，我在设计软件架构时遇到了困难。 我正在寻求帮助讨论一个好的方法。

我有的

我的代码库将包含三个项目

• MyApp.API
• MyApp.Repositories（数据访问层）
• MyApp.Services（业务逻辑）

我将实现IUnitOfWork内MyApp.Repositories并创建一个具体的SqlUnitOfWork在MyApp.API 。 Startup.cs会将IUnitOfWork注册到SqlUnitOfWork 。 稍后，当我获得更多数据源（Mongo等）时，我可以合并一个UnitOfWorkFactory 。

问题

1. 我应该在Startup.cs注册每个存储库还是仅将它们添加为IUnitOfWork属性？ 这里的想法是我会在我的控制器，服务和存储库中使用依赖注入，但只需要注入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容器中，并在EF Core中配置DbContext

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

之后，将其他服务注册到需要我们上下文的DI容器将非常容易，因为容器将解决我们的依赖关系。

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

希望这能回答你的问题。 如果没有，请告诉我。