.NetCore框架由于比较年轻,所以对它的使用也不像.NetFromework框架那样傻瓜,需要开发者自己进行一些配置,程序才能被执行。

  • 数据层中:

1、Context的引用依赖从EntityFramework更改为Microsoft.EntityFrameworkCore.SqlServer。

2、映射配置类由EntityTypeConfiguration<TEntity>更改为IEntityTypeConfiguration<TEntity>。实体类型配置由实现变为接口,这也侧面反映了.NetCore框架是基于依赖注入思想构建的,所以它在依赖注入的实现上比.NetFromework框架显的更为自然、有机和流畅。

3、启用自动检测更改由_eFContextRepository.Configuration.AutoDetectChangesEnabled = false更改为 _coreContextRepository.ChangeTracker.AutoDetectChangesEnabled = false。当批量添加修改数据时,EF同步到上下文这个阶段比较耗时。出现这个问题的原因是:每次调用Add、Update之前,EF都会调用AutoDetectChangesEnabled ()。微软官方给出的介绍是:

获取或设置一个值,该值指示是否通过 DbContext 和相关类的方法自动调用 AutoDetectChangesEnabled () 方法。 默认值为 true。
当查询数据时EF上下文便捕获了数据的快照,当调用DetectChanges方法时,会扫描上下中所有实体并将当前值和快照中的值进行比较,然后作出相关的行为。但是基于上述应意识到它的缺点,实体对象的改变与EF的ObjectStateManager之间是无法进行同步的。(所以这也就解释了在EF中,将AutoDetectChangesEnabled默认启动的原因,即值为“true”。)
解决速度慢的方法是:
AutoDetectChangesEnabled = false。
所以在执行批量添加修改数据的操作时,都会先将AutoDetectChangesEnabled的值显式的定义为“false”。
  • 启动项中:

在与数据库连接上.NetFramework框架通过App.config文件中配置的与SQL Service数据库连接的字符串值,可以很容易和傻瓜式方式直接与SQL Service数据库连接,并能执行与数据相关的操作。在.NetCore架框中是通过json文件(一般情况上为appsettings.json)中的配置与SQL Service数据库连接的字符串值,在字符串值配置好后并不能直接与SQL Service数据库连接并能执行与数据相关的操作,还需要通过托管环境配置构建器来获取这个字符串值,并赋值给DbContext的继承类,到此才能实现SQL Service数据库连接并能执行与数据相关的操作的功能。

       在.NetCore架框中如果在appsettings.json文件中定义了SQL Service数据库连接的字符串值,托管环境配置构建器就不一定能够获取这个字符串的值,在执行程序时产生异常。这是因为需要对appsettings.json文件的属性做一些配置,才能解决上述异常。

启动项在调式时都是通过Directory.GetCurrentDirectory()方法,从启动项的~bin\Debug\netcoreappX.X文件中查找appsettings.json文件读取数据库连接字符串,同时通过一系列其它的操作达到与数据库连接目,但是实际上appsettings.json文件的一般定义在启动项的根目录中,所以在默认情况下是不但找不appsettings.json文件,更不要说读取其中的数据与数据库取得连接了。

    要解决上述问题,是对启动项的appsettings.json文件的相关属性进行设置:把“复制到输出目录”的值由“不复制”;“生成操作”的值由“无”(图1)更改为“如果较新则复制” ;更改为“内容”(图2)。

.net core cs框架 .net core开发框架_框架

在程序生成或调式,或启动项根目中的录appsettings.json文件有更改时,会复制启动项根目中的录appsettings.json文件到启动项的~bin\Debug\netcoreappX.X文件中,实际上nopCommerce程序也是这样干的。这样就解决了不能查找并读取appsettings.json文件的问题。实际上在一个新创建的“ASP.NET Core Web 应用程序”中的appsettings.json文件的相关属性的默认值即为:“如果较新则复制”和“内容”。

三、.NerCore框架对性能的影响

.net core cs框架 .net core开发框架_.net core cs框架_02

.net core cs框架 .net core开发框架_框架_03

       通过使用MiniProfiler性能监视器和内存进程序对.NetFramework和.NetCore框架两者的在10组1000次量级读写性能进行对比, 大量数据流平均写入的速度上.NetCore框架仅有.NetFramework框架的2.5%,内存使用.NetFramework框架为72.7(MB),而.NetCore框架为45.8(MB).NetCore框架为.NetFramework框架的65%。所不管从写入速度,还是内存的使用在性能方面.NetCore框架比.NetFramework框架有着显著的优势。

四、在.NerCore框架Web环境中怎样对MiniProfiler性能监视器进行配置。

ConfigureServices(IServiceCollection services)方法中添加语句:services.AddMiniProfiler(configureOptions: options =>
            {
                options.PopupRenderPosition = RenderPosition.Right;
                options.PopupShowTimeWithChildren = true;
            }).AddEntityFramework(); // 添加MiniProfiler.EntityFrameworkCore  NuGet-----MiniProfiler.EntityFrameworkCore
2、在Configure(IApplicationBuilder app, IWebHostEnvironment env)方法中添加语句:
// 添加MiniProfiler管道。
app.UseMiniProfiler();
3、在_ViewImports.cshtml文件中分别添加语句:
@addTagHelper *, MiniProfiler.AspNetCore.Mvc
@using StackExchange.Profiling
4、在_Layout.cshtml文件中添加标签:
<mini-profiler />
2019-12-20_NoIOCCore(001控制台动态实例UnitOfWork调用模式,完成Insert、Update、Delete数据操作验证) -- 。
2019-12-20_NoIOCCore(002控制台动态实例UnitOfWork调用模式,MiniProfiler10组1000次读写性能监视) --。
2019-12-20_NoIOCCore(003WEB动态实例UnitOfWork调用模式,MiniProfiler读写性能监视)  --。