怎么做国外的网站,外贸营销型网站制作,人才交流中心招聘网站建设方案,wordpress留言功能在EF Core 5中#xff0c;有很多方式可以窥察工作流程中发生的事情#xff0c;并与该信息进行交互。这些功能点包括日志记录#xff0c;拦截#xff0c;事件处理程序和一些超酷的最新出现的调试功能。EF团队甚至从Entity Framework的第一个版本中恢复了一些有用的旧的功能。… 在EF Core 5中有很多方式可以窥察工作流程中发生的事情并与该信息进行交互。这些功能点包括日志记录拦截事件处理程序和一些超酷的最新出现的调试功能。EF团队甚至从Entity Framework的第一个版本中恢复了一些有用的旧的功能。本博文带你更深入地研究访问EF Core 5的一些元数据和其有趣的使用方式。1、将EF的ToTraceString移植为EF Core的ToQueryString这是回忆杀。在Entity Framework的第一个迭代版本中没有内置的日志记录。但是有ObjectQuery.ToTraceString这是一种运行时方法可以动态计算LINQ或Entity SQL查询的SQL尽管这不是一个很好的日志记录方法但它毕竟可以输出SQL即使在今天也有一些有用的场景。直到最新版本EF Core 5该功能才成为EF Core的一部分并且已重命名为ToQueryString。如果要查看实体类People的简单查询所生成的SQL只需将ToQueryString附加到查询中即可。不涉及LINQ执行方法。换句话说将查询本身与执行方法分开仅仅针对查询。var sqlFromQuerycontext.People.ToQueryString();
ToQueryString的一个有趣用例是在调试时查看其结果不必等到运行方法即可检查日志中的SQL。例如我可以构建查询捕获字符串然后执行查询。private static void GetAllPeople()
{using var context new PeopleContext();var query context.People.Where(pp.FirstNameJulie);var sqlFromQuery query.ToQueryString();var people query.ToList();
}
然后在调试时可以看到sqlFromQuery变量的预期SQL。当然您不需要将此代码嵌入生产代码中。实际上也非常不建议这样做因为当EF Core进行SQL编制过程时它很容易影响性能。您应该可以在调试器中调用ToQueryString如图所示。在调用ToQueryString之前查询变量已经作为DbQuery进行了评估因此可以正常工作。调试上下文并在调试器中直接显示DbSet例如在调试器中成功运行context.People.ToQueryString但是您不能直接评估LINQ表达式。换句话说如果要调试上下文变量然后在调试器中使用Where方法它将失败。这并不是什么新鲜事物也不是ToQueryString的限制。关于ToQueryString的最后一个要点是对它的评估基于最简单的执行ToList。使用诸如FirstOrDefault之类的LINQ执行查询会影响SQL的呈现方式因此在使用FirstOrDefault执行查询时ToQueryString呈现的SQL与发送给数据库的SQL不同。这种情况下需要 EF Core日志记录来打印准确的Sql而不是还执拗于ToQueryString。我发现在集成测试场景下ToQueryString特别有用。如果您需要编写测试测试的成功取决于生成的SQL表达式的某些部分那么ToQueryString是比日志记录更简单的路径。使用日志记录时您必须将日志捕获到文本编写器中然后读取该文本。尽管使用InMemory提供程序可能很诱人但请记住InMemory提供程序不会生成SQL。您需要为真实数据库使用提供程序数据库不需要存在即可使用ToQueryString。EF Core在内存中才能确定SQL。这是一个演示测试示例旨在证明EF Core编写的智能SQL比我编写的更为智能。请注意我在测试项目中引用了Microsoft.EntityFrameworkCore.Sqlite提供程序。如您所知EF和EF Core总是投影与实体属性相关的列。它不写SELECT *。[TestMethod]
public void SQLDoesNotContainSelectStar()
{var builder new DbContextOptionsBuilder();builder.UseSqlite(Data Sourcetestdb.db);using var context new PeopleContext(builder.Options);var sqlcontext.People.ToQueryString();Assert.IsFalse(sql.ToUpper().Contains(SELECT *));
}
如果您使用拦截器来执行软删除并且使用全局查询过滤器来始终过滤出这些行。例如这是我DbContext OnModelBuildling方法中的一个查询过滤器它告诉EF Core过滤掉IsDeleted属性为true的Person行。modelBuilder.EntityPerson().HasQueryFilter(p !p.IsDeleted);
有了这个我可以编写与上面类似的测试但是将断言更改为以下内容以确保我不会破坏全局查询过滤器逻辑。Assert.IsTrue(sql.ToUpper().Contains(WHERE NOT (\p\.\IsDeleted\)));
2、从EF Core记录详细信息共有三种方法可以利用EF Core的日志管道。2.1、 简单的日志记录可以与.NET的日志记录API结合使用所有的繁重辛苦的工作都是在后台进行的。您可以使用LogTo方法轻松配置DbContext将.NET日志记录输出。嗯我就想看着你就这样子简简单单。EF Core将输出很多事件。分为以下类这些类从DbCloggerCategory派生。变更追踪ChangeTracking数据库命令Database.Command数据库连接Database.Connection数据库事务Database.Transaction数据库Database基础设施Infrastructure移居Migrations模型验证Model.Validation模型Model询问Query脚手架Scaffolding更新Update您可以使用这些类别将输出筛选为要记录的信息类型。LogTo的一个参数指定目标为控制台窗口、文件或调试窗口。然后第二个参数允许您通过.NET LogLevel以及您感兴趣的任何DLoggerCategoy进行筛选。此示例配置DbContext将日志输出到控制台并过滤掉所有DbLoggerCategory类型LogLevel.Information组。optionsBuilder.UseSqlServer(myConnectionString)
.LogTo(Console.WriteLine,LogLevel.Information);
下面一个LogTo方法添加了第三个参数-DbLoggerCatetory数组仅包含一个数组以便仅对EF Core的数据库命令进行进一步过滤。与LogTo方法一起我添加了EnableSensitiveDataLogging方法以在SQL中显示传入参数。这将捕获所有发送到数据库的SQL查询更新原始SQL甚至通过迁移发送的更改。.LogTo(Console.WriteLine, LogLevel.Information,new[]{DbLoggerCategory.Database.Command.Name},
)
.EnableSensitiveDataLogging();
上面包含IsDeleted属性的“Person”类型也具有FirstName和LastName属性。这是添加新的Person对象后调用SaveChanges的日志。info: 1/4/2021 17:56:09.935RelationalEventId.CommandExecuted[20101](Microsoft.EntityFrameworkCore.Database.Command)Executed DbCommand (22ms) [Parameters[ p0Julie (Size 4000), p1False, p2Lerman (Size 4000)],CommandTypeText,CommandTimeout30]SET NOCOUNT ON;INSERT INTO [People] ([FirstName],[IsDeleted], [LastName])VALUES (p0, p1, p2);SELECT [Id]FROM [People]WHERE ROWCOUNT 1 AND [Id] scope_identity();
日志记录显示信息类型、EventId、以及请求的记录器类别的详细信息。接下来日志名称执行时间和参数列表。由于启用了敏感数据记录因此将显示参数。最后它列出了发送到数据库的SQL。LogTo使EF Core输出基本日志记录变得容易。您可以在DbContextASP.NET Core应用程序的启动文件或ASP.NET Core应用程序的应用程序配置文件中对其进行配置。注意顶部的EventId。您甚至可以定义日志记录以使用这些ID过滤特定事件。您还可以过滤出特定的日志类别并且可以控制格式。在https://docs.microsoft.com/zh-cn/ef/core/logging-events-diagnostics/simple-logging上查看有关这些各种功能的更多详细信息的文档。简单日志记录是记录EF Core的高级方法是的高级的就是简单的这就是计算机世界的定义您也可以通过直接与Microsoft.Extensions.Logging一起以对EF Core的日志方式进行更多控制。检查EF Core文档以获取更多有关使用此更高级用法的详细信息https://docs.microsoft.com/zh-cn/ef/core/logging-events-diagnostics/extensions-logging。2.2、响应EF Core 事件EF Core 2.1在EF Core管道中引入了.NET事件。开始只有两个ChangeTracker.Tracked在DbContext开始跟踪实体时引发和ChangeTracker.StateChanged在已跟踪的实体的状态改变时引发。后来看久了生情事件的家族又迎来了几个小家伙......有了基本逻辑团队向EF Core 5添加三个事件SaveChangesFailed、SaveChanges和SaveChangesAsync。当上下文将要保存更改时将引发DbContext.SavingChanges。在两个保存更改方法中的任何一个成功完成之后将引发DbContext.SavedChanges。DbContext.SaveChangesFailed用于捕获和检查故障。能够分离此逻辑而不是全部填充到SaveChanges方法的中这是一个很好的选择。可以使用这些事件来记录未跟踪的备用信息您甚至可以使用事件来发出记录器无法跟踪的备用信息。如果要使用影子属性跟踪审核数据则可以在构造SQL并将其发送到数据库之前使用SavingChanges事件更新这些属性。例如我将应用程序设置为向每个实体添加UserId阴影属性不包括那些属性包和拥有的实体。当用户登录时我的应用程序有一个名为Globals.CurrentUserId的静态变量。此外在我的DbContext类中我创建了一个名为SetUserId的私有方法该方法将我的shadow属性存在的地方的值设置为CurrentUserId。private void SetUserId(object sender, SavingChangesEventArgs e)
{foreach (var entry in ChangeTracker.Entries().Where(entry entry.Metadata.GetProperty(UserId) ! null)){entry.Property(UserId).CurrentValue Globals.CurrentUserId;}
}
最后我可以将SetUserId方法连接到DbContext的构造函数中的SavingChanges事件public PeopleContext()
{SavingChanges SetUserId;
}
现在每当我调用SaveChanges时UserId就会与其他数据一起持久保存到表中。这是一些日志数据Executed DbCommand (29ms) [Parameters[p0Julie (Size 4000), p1False, p2Lerman (Size 4000), p3101], CommandTypeText, CommandTimeout30]SET NOCOUNT ON;
INSERT INTO [People] ([FirstName],[IsDeleted], [LastName], [UserId])
VALUES (p0, p1, p2, p3);
SELECT [Id]
FROM [People]
WHERE ROWCOUNT 1AND [Id] scope_identity();
这只是利用这些事件的一种简单方法。2.3、使用事件计数器访问指标EF Core 5利用了.NET Core 3.0中.NET引入的一项很酷的功能-dotnet-countershttps://docs.microsoft.com/zh-cn/dotnet/core/diagnostics/dotnet-counters。计数器是一个全局命令行工具。您可以使用dotnet CLI安装此工具。dotnet tool install --global dotnet-counters安装完成后您可以告诉它监视在dotnet环境中运行的进程。您需要提供正在运行的.NET应用程序的进程IDSystem.Diagnostics.Process.GetCurrentProcess().Id
在Visual Studio中我无法简单地在调试器中调试此值。调试器只会告诉您“此表达式会产生副作用因此不会被评估。” 因此我将其嵌入到我的代码中并获得了值313131。在拥有ID且应用仍在运行的情况下然后可以触发计数器开始监视来自Microsoft.EntityFramework命名空间的事件。如下dotnet counters monitor Microsoft.EntityFrameworkCore -p 313131
然后当您遍历应用程序时计数器将显示EF Core统计信息的特定列表如图所示然后在应用程序执行其功能时更新计数。我仅监视了一个小型演示应用程序因此计数并不是很好看但是您可以看到我正在运行一个DbContext实例Active DbContexts我已经运行了三个查询并利用了查询缓存因为我运行了其中一些查询不止一次并两次调用SaveChanges。这看起来像您的代码分析工具但是当针对更密集的解决方案运行时它肯定会更有用。EF团队建议您在文档中仔细阅读dotnet-counters功能以便正确使用EF Core。3、拦截EF Core的数据——拦截器EF Core的拦截器是一项功能该功能始于EF6并在EF Core 3中重新引入。EF Core 5中引入了SaveChanges的新拦截器。由于此功能已经存在很长时间了尽管它对于EF Core是相当新的因此应该有很多文章介绍。即使这样我还是觉得很神奇。共有三种不同的拦截器类来拦截命令连接和事务以及用于SaveChanges的新拦截器类。每个类都有自己相关的虚拟方法和相关对象。例如DbCommandInterceptor公开了ReaderExecuting和ReaderExecutingAsync它们在命令即将发送到数据库时被触发。public override InterceptionResultDbDataReaderReaderExecuting(DbCommand command,CommandEventData eventData,InterceptionResultDbDataReader result){//例如webmote支持你干点啥?return result;}
它的参数之一是DbCommand其CommandText属性保存SQL。如果要修改SQL添加查询提示或其他任务则可以更改命令然后使用新CommandText值的命令将继续进行。从数据库返回任何结果数据时将触发ReaderExecuted / Async方法。public override DbDataReader ReaderExecuted(DbCommand command,CommandExecutedEventData eventData,DbDataReader result){return base.ReaderExecuted(command, eventData, result);}
例如在这里您可以捕获DbDataReader并对该数据进行某些处理然后再继续执行EF Core实现。一个示例是记录一些记录器无法捕获的内容例如:4、查询拦截EF Core 公开的 DbCommandInterceptor拦截器提供查询拦截功能查询拦截是在数据库上执行查询之前插入逻辑或者在查询执行之后以及控制返回到调用代码之前立即插入逻辑的能力。此功能在现实世界中有多种使用案例延长具有某些特征的命令的超时查询失败并记录异常时诊断信息当读取到内存的行数超过特定阈值时记录警告一个小例子public class TestQueryInterceptor : DbCommandInterceptor
{// runs before a query is executedpublic override InterceptionResultDbDataReader ReaderExecuting(DbCommand command, CommandEventData eventData, InterceptionResultDbDataReader result){command.CommandText OPTION (OPTIMIZE FOR UNKNOWN); command.CommandTimeout 12345; return result;}// runs after a query is excutedpublic override DbDataReader ReaderExecuted(DbCommand command, CommandExecutedEventData eventData, DbDataReader result){if (this.ShouldChangeResult(command, out var changedResult)){return changedResult;}return result;}
}
注意 大多数方法都有同步和异步版本。令人讨厌的是异步查询仅触发异步方法反之亦然因此在编写拦截器时必须覆盖两者。安装拦截器是很简单的。public class SampleDbContext : DbContext
{protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder){optionsBuilder.UseSqlite(Data SourceSample.db;).AddInterceptors(new TestQueryInterceptor (), new SampleInterceptor2());}
}
通过返回InterceptionResultT.SuppressWithResult()禁止执行。重要的是要注意DbCommandInterceptor安装的其他所有组件仍将执行并且可以通过上的HasResult属性检查其他拦截器是否已禁止执行result。public override InterceptionResultobject ScalarExecuting(DbCommand command, CommandEventData eventData, InterceptionResultobject result)
{if (this.ShouldSuppressExecution(command)){return InterceptionResult.SuppressWithResultobject(null);}return result;
}
方法中引发的异常从技术上将阻止执行不要利用这个事实将异常用于控制流几乎总是很糟糕的设计。你可以拦截如下清单的操作方法操作CommandCreating在创建命令之前注意一切都是命令因此它将拦截所有查询CommandCreated创建命令之后但执行之前CommandFailed[Async]在执行过程中命令失败并出现异常后ReaderExecuting[Async]在执行“查询”命令之前ReaderExecuted[Async]执行“查询”命令后NonQueryExecuting[Async]在执行“非查询”命令之前注意非查询的一个示例是 ExecuteSqlRawNonQueryExecuted[Async]执行“非查询”命令后ScalarExecuting [Async]在执行“标量”命令之前注意“标量”是存储过程的同义词ScalarExecuted [Async]执行“标量”命令后DataReaderDispose执行命令后这是一个耗时命令拦截public class MyDBCommandInterceptor: DbCommandInterceptor
{public static ConcurrentDictionary CommandStartTimes new ConcurrentDictionary();public static ConcurrentDictionary CommandDurations new ConcurrentDictionary();public override void NonQueryExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) {CommandStartTimes.TryAdd(command, DateTime.Now);base.NonQueryExecuting(command, interceptionContext);}public override void ReaderExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) {CommandStartTimes.TryAdd(command, DateTime.Now);base.ReaderExecuting(command, interceptionContext);}public override void ScalarExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) {CommandStartTimes.TryAdd(command, DateTime.Now);base.ScalarExecuting(command, interceptionContext);}public override void NonQueryExecuted(DbCommand command, DbCommandInterceptionContext interceptionContext) {base.NonQueryExecuted(command, interceptionContext);AccumulateTime(command);}public override void ReaderExecuted(DbCommand command, DbCommandInterceptionContext interceptionContext) {base.ReaderExecuted(command, interceptionContext);AccumulateTime(command);}public override void ScalarExecuted(DbCommand command, DbCommandInterceptionContext interceptionContext) {base.ScalarExecuted(command, interceptionContext);AccumulateTime(command);}private void AccumulateTime(DbCommand command) {if (CommandStartTimes.TryRemove(command, outvar commandStartTime)) {var commandDuration DateTime.Now - commandStartTime;CommandDurations.AddOrUpdate(command.CommandText, commandDuration, (_, accumulated) commandDuration accumulated);}}
}
有关使用EF Core文档中的拦截器的大量指导请访问https://docs.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors。5、EF Core 5中的Sleeper功能调试视图就是 ChangeTracker.DebugView和Model.DebugView。DebugViews输出格式正确的字符串其中有ChangeTracker的状态或模型中的元数据的信息。DebugView提供了一个漂亮的文档您可以捕获和打印该文档并真正了解其幕后情况。我在调试器上花费了大量时间以探索有关变更跟踪器了解的内容或EF Core如何解释我所描述的模型的各种详细信息。能够以这种文本格式读取此信息甚至将其保存在文件中因此您无需反复调试即可收集详细信息这是EF Core 5的一项神奇功能。确保您了解DebugViews是撰写本文的目的。在DbContext.ChangeTracker.DebugView中您将找到ShortView和LongView属性。例如这里是我刚查询一个Person对象时的视图而我的上下文仅包含一个人。Person {Id: 1} Unchanged
这是最常用的信息-在我的上下文中只有一个未更改的Person的ID为1。LongView提供了有关被跟踪实体的更多详细信息。Person {Id: 1} UnchangedId: 1 PKFirstName: JulieIsDeleted: FalseLastName: LermanUserId: 101Addresses: []
如果要在跟踪的Person上对其进行编辑并强制上下文检测更改则LongView除了将状态显示为Modified之外还对LastName属性所做的更改进行记录。Person {Id: 1} ModifiedId: 1 PKFirstName: JulieIsDeleted: FalseLastName: Lermantov ModifiedOriginally LermanUserId: 101Addresses: []
您可以在此视图中看到一个Addresses属性。实际上使用导航“人”和“地址”之间存在多对多关系。EF Core在运行时推断内存中的PersonAddress实体以便将关系数据持久化到联接表中。当我在其“地址”集合中创建一个具有一个地址的人的图形时您可以在ShortView中看到一个“人”一个地址和一个推断的PersonAddress对象。长视图显示了这些对象的属性。AddressPerson (Dictionarystring, object){AddressesId: 1, ResidentsId: 1} Unchanged FK{AddressesId: 1} FK {ResidentsId: 1}
Address {Id: 1} Unchanged
Person {Id: 1} Modified
我喜欢这些调试视图这些视图可以在调试时帮助我发现被跟踪对象的状态和关系无论我是在解决问题还是在学习它的工作方式。让我们转到Model.DebugViews看看您可以从中学到什么。首先我应该阐明我的模型。使用Visual Studio中的EF Core Power Tools扩展来可视化模型。DbContext.Model.DebugView也具有ShortView和LongView。它们都包含很多信息。您可以看到属性主键和外键索引以及级联删除规则,多对多关系甚至指定了它使用跳过导航。还描述了继承。您可以从这份文件中学到很多东西。清单1数据模型的Model.DebugView.ShortViewModel:EntityType: AddressPerson (Dictionarystring, object) CLR Type: Dictionarystring, objectProperties:AddressesId (no field, int) Indexer Required PK FK AfterSave:ThrowResidentsId (no field, int) Indexer Required PK FK Index AfterSave:ThrowKeys:AddressesId, ResidentsId PKForeign keys:AddressPerson (Dictionarystring, object) {AddressesId} - Address {Id} CascadeAddressPerson (Dictionarystring, object) {ResidentsId} - Person {Id} CascadeIndexes:ResidentsIdEntityType: AddressProperties:Id (int) Required PK AfterSave:Throw ValueGenerated.OnAddPostalCode (string)Street (string)UserId (no field, int) Shadow RequiredNavigations:WildlifeSightings (ListWildlifeSighting) Collection ToDependent WildlifeSightingSkip navigations:Residents (ListPerson) CollectionPerson Inverse: AddressesKeys:Id PKEntityType: PersonProperties:Id (int) Required PK AfterSave:Throw ValueGenerated.OnAddFirstName (string)IsDeleted (bool) RequiredLastName (string)UserId (no field, int) Shadow RequiredSkip navigations:Addresses (ListAddress) CollectionAddress Inverse: ResidentsKeys:Id PKEntityType: WildlifeSightingProperties:Id (int) Required PK AfterSave:Throw ValueGenerated.OnAddAddressId (int) Required FK IndexDateTime (DateTime) RequiredDescription (string)UserId (no field, int) Shadow RequiredKeys:Id PKForeign keys:WildlifeSighting {AddressId} - Address {Id} ToDependent: WildlifeSightings CascadeIndexes:AddressId
Model.DebugView.LongView包含更多详细信息它们描述了注释数据库映射等。您可以从LongView中学到更多,但并不是每个人都希望看到这种细节如果您需要它就在那里。清单2在Model.DebugView的LongView中描述的Person实体EntityType: PersonProperties:Id (int) Required PK AfterSave:Throw ValueGenerated.OnAddAnnotations:Relational:DefaultColumnMappings: System.Collections.Generic.SortedSet1 [Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMappingBase]Relational:TableColumnMappings: System.Collections.Generic.SortedSet1 [Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMapping]SqlServer:ValueGenerationStrategy: IdentityColumnFirstName (string)Annotations:Relational:DefaultColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMappingBase]Relational:TableColumnMappings:System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMapping]IsDeleted (bool) RequiredAnnotations:Relational:DefaultColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMappingBase]Relational:TableColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMapping]LastName (string)Annotations:Relational:DefaultColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMappingBase]Relational:TableColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMapping]UserId (no field, int) Shadow RequiredAnnotations:Relational:DefaultColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMappingBase]Relational:TableColumnMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.ColumnMapping]Skip navigations:Addresses (ListAddress) CollectionAddress Inverse: ResidentsKeys:Id PKAnnotations:Relational:UniqueConstraintMappings: System.Collections.Generic.SortedSet1[Microsoft.EntityFrameworkCore.Metadata.Internal.UniqueConstraint]Annotations:ConstructorBinding: Microsoft.EntityFrameworkCore.Metadata.ConstructorBindingQueryFilter: p Not(p.IsDeleted)Relational:DefaultMappings: System.Collections.Generic.List1[Microsoft.EntityFrameworkCore.Metadata.Internal.TableMappingBase]Relational:TableMappings: System.Collections.Generic.List1[Microsoft.EntityFrameworkCore.Metadata.Internal.TableMapping]Relational:TableName: PeopleServiceOnlyConstructorBinding: Microsoft.EntityFrameworkCore.Metadata.ConstructorBinding
6、利用有关EF Core您对幕后情况了解得越多对该工具的掌控力就越大。了解EF Core如何解释您的类和映射你可以控制这些模型并按照您希望的方式持久保存数据也可以根据需要修改SQL甚至结果。学习如何利用本文中介绍的各种调试日志记录侦听和事件处理方法希望能帮助您成为团队中的EF Core专家。当然不用多久,你就会升职加薪、当上总经理、出任CEO、迎娶白富美、走上人生巅峰,想想是不是还有点小激动
