使用数据访问层安排3层的dotnet核心应用程序

ric*_*ver 6 .net c# asp.net entity-framework

我典型的.NET 4.5X Web应用程序结构至少包含3层:Web项目(.NET Web应用程序),域/业务逻辑项目(类库)和数据访问项目(类库).Web项目引用业务层,业务层引用数据访问层.

我喜欢这种方法,因为我的web项目没有对数据访问项目的引用(它必须首先通过域/业务逻辑层).我的Web项目不应该具有对上下文或存储库类的任何访问权限.

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

在新的Dotnet Core范例中,我看到的每个示例都在Startup.cs中配置了DbContext,如下所示:

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

通过为启动提供一个用于dbcontext的具体类,我必须引用数据访问项目,其中定义了dbcontext.我宁愿只引用中间层,并避免引用DAL.

我的问题是:我应该如何安排我的解决方案结构,以便我可以避免从我的Web项目添加引用到我的数据访问项目?

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

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

点网核心有什么重要的缺点吗?

先感谢您.

ric*_*ver 6

我找到了一个使用EF6和Dotnet Core的解决方案,我很满意.

它不使用对EF7的services.AddSqlServer()调用,而是使用EF6配置并在启动时调用的Bootstrap类中注册DbContext.

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

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

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

    services.RegisterApplicationServices(Configuration);
}
Run Code Online (Sandbox Code Playgroud)

在此输入图像描述

WebLibrary是点网核心Web应用程序(包含控制器,是启动项目).

业务逻辑是服务层,是Web应用程序和数据访问项目之间的中间层.

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

Model项目包含POCO和Enums,而不是智能对象,而是整个应用程序中使用的容器.

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

查看github repo以获取示例解决方案. 我仍然有一个问题,具体到我的应用程序是这样的:

即使Web库没有对数据访问项目的引用,我仍然可以从其中一个控制器实例化ApplicationContext.将这些项目分开的重点是,我无法直接在Web项目中获取数据库上下文.我不确定这是否与Core中的新解决方案结构相关,或者我是否包含了我不知道的内容.

  • 在你的尝试中做得很好,有时候我想知道是否值得所有的努力只是为了防止上下文泄漏到不应该的层次,一个有能力的开发人员可信赖的团队可能会在没有滥用可访问上下文这一事实的情况下得到 (3认同)