使用数据访问层安排3层的dotnet核心应用程序 [英] Arranging dotnet core app for 3-tiers with data access layer

问题描述

我的典型的.NET 4.5X Web应用程序结构至少有3层：一个Web项目（一个.NET Web应用程序），一个域/业务逻辑项目（一个类库）和一个数据访问项目图书馆）。 Web项目引用业务层，业务层引用数据访问层。

我喜欢这种方法，因为我的Web项目没有引用数据访问项目（必须首先通过域/业务逻辑层）。我的Web项目不应该有任何访问上下文或存储库类。

在3层的.net 4.5.X应用程序中，我声明连接字符串在web.config，并将DbContext的名称作为连接字符串的name属性。

在新的Dotnet Core范例中，我看到的每个示例都将配置了DbContext Startup.cs这样：

  public void ConfigureServices（IServiceCollection services）
 {
 //添加框架服务。 
 services.AddMvc（）; 
 services.AddEntityFramework（）
 .AddSqlServer（）
 .AddDbContext< MyApplicationContext>（myconnectionstring或引用它）; 
} 
  

通过给启动一个具体的类用于dbcontext，我必须引用数据访问项目，其中定义了dbcontext。我更喜欢仅引用中间层，并避免引用DAL。

我的问题是：我应该如何安排我的解决方案结构，以便我可以避免添加从我的网站项目引用到我的数据访问项目？

我可以使用appsettings.json属性吗？

我可以添加我的实体配置另一种方式吗？

有没有什么重要的我缺少点网络核心？

谢谢你提前。

解决方案

我发现一个使用EF6和Dotnet Core的解决方案，我相当舒服。 p>

它不使用对EF7的services.AddSqlServer（）调用，而是使用EF6配置，并在启动时调用的Bootstrap类中注册DbContext。

  public static class BootstrapConfig 
 {
 public static void RegisterApplicationServices（此IServiceCollection服务，IConfigurationRoot配置）
 {
 // DbContext 
 services.AddScoped< DbContext>（x => new ApplicationContext（configuration [Data：ApplicationContext：ConnectionString]））; 
} 
} 
  

这是从WebLibrary中的Startup.cs调用的项目为

  public void ConfigureServices（IServiceCollection services）
 {
 //添加框架服务。 
 services.AddMvc（）; 
 
 services.RegisterApplicationServices（Configuration）; 
} 
  

WebLibrary是点网核心Web应用程序（包含控制器，是启动项目）。

业务逻辑是服务层，是网络应用程序和数据访问项目之间的中间层。

数据访问是实际执行查询的dbContext和存储库类所在的位置。

Model项目包含POCOs和枚举，而不是智能对象，而是跨越应用程序。

Bootstrap项目引用了业务逻辑和数据访问项目，以便它可以注册IOC容器的服务和存储库。

查看示例解决方案的 github repo 。
我仍然有一个问题，具体到我的应用程序是这样的：

即使网络库没有引用数据访问项目，我仍然可以从其中一个控制器实例化一个ApplicationContext。将这些项目分开的全部要点是，我无法直接在Web项目中获取数据库环境。我不知道这是否与Core中的新解决方案结构相关，或者我是否包含我不知道的内容。

My typical .NET 4.5X web application structure has a minimum of 3 tiers: a web project (a .NET web application), a domain/business logic project (a class library), and a data access project (a class library). The web project references the business layer, and the business layer references the data access layer.

I like this approach since my web project does not have a reference to the data access project (it must go through the domain/business logic layer first). My web project shouldn't have any access to the context or repository classes.

In the 3-tiered .net 4.5.X app, I declare the connection string in the web.config and give the name of the DbContext as the name attribute of the connection string.

In the new Dotnet Core paradigm, every example I see has the DbContext configured in the Startup.cs like this:

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();
    services.AddEntityFramework()
        .AddSqlServer()
        .AddDbContext<MyApplicationContext>("myconnectionstring  or reference to it");
}

By giving the startup a concrete class to use for the dbcontext, I must reference the data access project, where the dbcontext is defined. I would prefer to only reference the middle tier, and avoid the reference to the DAL.

My question is: how should I arrange my solution structure so that I can avoid adding a reference from my web project to my data access project?

Can I use an appsettings.json property?

Can I add my Entity configuration another way?

Is there something major I am missing about dot net core?

Thank you in advance.

解决方案

I found a solution using EF6 and Dotnet Core that I am fairly comfortable with.

It doesn't use the services.AddSqlServer() call for EF7, but rather uses an EF6 configuration and registers the DbContext in a Bootstrap class called at Startup.

public static class BootstrapConfig
{
    public static void RegisterApplicationServices(this IServiceCollection services, IConfigurationRoot configuration)
    {
        // DbContext
        services.AddScoped<DbContext>(x => new ApplicationContext(configuration["Data:ApplicationContext:ConnectionString"]));
    }
}

This is called from the Startup.cs in the WebLibrary project as

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();

    services.RegisterApplicationServices(Configuration);
}

WebLibrary is the dot net core web application (contains controllers, is the startup project).

Business logic is the service layer, and is the middle tier between the web app and the data access project.

Data Access is where the dbContext and repository classes exist for actually doing a query.

The Model project holds POCOs and Enums, not smart objects but containers that are used across the application.

The Bootstrap project has a reference to both the business logic and data access projects so that it can register the services and repositories for the IOC container.

Check out the github repo for the example solution. One problem I still have, specific to my application is this:

Even though the web library does not have a reference to the data access project, I can still instantiate an ApplicationContext from one of the controllers. The whole point of separating these projects out was so I could make it impossible to get a db context directly in the web project. I'm not sure if that's related to the new solution structure in Core or if I'm including something I am unaware of.

这篇关于使用数据访问层安排3层的dotnet核心应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！