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

Question

我正在尝试为我的 ASP.NET Core API 推出高性能 DAL。我想使用 ADO.NET，但在设计软件架构时遇到了困难。我正在寻求帮助讨论一个好的方法。我有的我的代码库将包含三个项目我的应用程序APIMyApp.Repositories（数据访问层）MyApp.Services（业务逻辑）我将IUnitOfWork在内部实现MyApp.Repositories并创建一个具体SqlUnitOfWork的MyApp.API. Startup.cs将注册IUnitOfWork到SqlUnitOfWork。稍后，当我获得更多数据源（Mongo 等）时，我可以合并一个UnitOfWorkFactory.问题我应该在每个存储库中注册Startup.cs还是简单地将它们添加为属性IUnitOfWork？这里的想法是我会在我的控制器、服务和存储库中使用依赖注入，但只需要注入IUnitOfWork.如何将我的连接字符串传递到SqlUnitOfWork? 我知道连接字符串应该保持在MyApp.API.

Answer 1

另一个答案是无关紧要的，因为它建议我使用 EF，这是我想避免的。

我用存储库模式实现了 Dapper。我没有使用工作单元，因为我认为这样做会导致我不希望出现的性能损失。

这是我实现的原始原型。 https://github.com/lenardchristopher/AdoAspDotNetCoreTest

Answer 2

我相信您正在使用 aspnet-core，因此使用实体框架作为您的 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>();

}

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