ef core

使用 .NET Core 实现一个自定义日志记录器在应用程序中，日志记录是一个至关重要的功能。不仅有助于调试和监控应用程序，还能帮助我们了解应用程序的运行状态。在这个示例中将展示如何实现一个自定义的日志记录器，先说明一下，这个实现和Microsoft.Extensions.Logging、Serilog、NLog什么的无关，这里只是将自定义的日志数据存入数据库中，或许你也可以理解为实现的是一个存数据的“Repository”，只不过用这个Repository来存的是日志🙈。这个实现包含一个抽象包和两个实现包，两个实现分别是用 EntityFramew

ASP.NET Core8.0学习笔记（二十六）——EF Core Include导航数据加载——显式加载1.应用场景：在前面使用Include方法加载依赖实体时，在加载主体实体时，依赖实体也会一并自动加载。但是某些时候我们只需要查询主体实体，没有必要加载依赖实体，或者说只有我们需要依赖实体时再去加载依赖实体。这就需要使用显式加载。

ASP.NET Core8.0学习笔记（二十五）——EF Core Include导航数据加载之预加载与过滤1.在EF Core中可以使用导航属性来加载相关实体。 2.加载实体的三种方式： (1)预先加载：直接在查询主体时就把对应的依赖实体查出来（作为初始查询的一部分） (2)显式加载：使用代码指示稍后显式的从数据库中加载数据 (3)延迟加载：在访问导航属性时，以透明的方式加载关联数据

ASP.NET Core8.0学习笔记（二十二）——单向导航属性1.双向导航属性存在的问题：数据库中存在一些“基础表”，这些表会被其他各种表来引用。比如有一张User表，另有请假表（请假人、审批人）、采购表（采购员、审核员）等多个表的多个属性都会引用这一张表。那么对于User这个实体，当中就会引用所有表实体作为导航属性，从而造成User表臃肿。 2.观察前文的两个实体：主体实体文章Article：

ASP.NET Core8.0学习笔记（二十一）——EFCore关系配置API依赖实体Comment这两个实体都没有符合默认约定的导航属性，因此必须要通过API进行手动配置。而对于关系的配置一定要体现出实体之间的联系，如一对一还是一对多。这两个实体很明显是一对多的关系。 3.关系配置API （1）EF Core中实体之间关系配置的套路： API名称：HasXXX()、WithXXX()，先Has后Many，HasXXX由主体实体指向依赖实体，参数为导航属性，WithXXX()由依赖实体指向主体实体，参数也是导航属性。所以API的名称有：一对多：HasOne()、WithMany

.NET 开源 EF Core 批处理扩展工具，真好用Entity Framework Core（EF Core）作为 .NET 生态系统中受欢迎的对象关系映射器（ORM），其轻量级、可扩展性和支持多个数据库引擎而备受青睐。

EntityFramework Core并发迁移解决方案目前一个项目中数据持久化采用EF Core + MySQL，使用CodeFirst模式开发，并且对数据进行了分库，按照目前颗粒度分完之后，大概有一两百个库，每个库的数据都是相互隔离的。借鉴了Github上一个开源的仓库 arch/UnitOfWork 实现UnitOfWork，核心操作就是每个api请求的时候带上库名，在执行CRUD之前先将DbContext切换到目标数据库，我们在切换数据库的时候加了一些操作，如检查数据库是否已创建、检查连接是否可用、判断是否需要表结构迁移等

ChaITSimpleLove

如何使用 ef core 的 code first（fluent api）模式实现自定义类型转换器？在使用 Entity Framework Core (EF Core) 的 Code First 模式时，如果你想在 SQLite 数据库中存储 JsonDocument or DateTime 类型的数据，需要确保数据类型的正确映射。

论如何直接用EF Core实现创建更新时间、用户审计，自动化乐观并发、软删除和树形查询（下）数据库并发，数据审计和软删除一直是数据持久化方面的经典问题。早些时候，这些工作需要手写复杂的SQL或者通过存储过程和触发器实现。手写复杂SQL对软件可维护性构成了相当大的挑战，随着SQL字数的变多，用到的嵌套和复杂语法增加，可读性和可维护性的难度是几何级暴涨。因此如何在实现功能的同时控制这些SQL的复杂度是一个很有价值的问题。而且这个问题同时涉及应用软件和数据库两个相对独立的体系，平行共管也是产生混乱的一大因素。

论如何直接用EF Core实现创建更新时间、用户审计，自动化乐观并发、软删除和树形查询（中）数据库并发，数据审计和软删除一直是数据持久化方面的经典问题。早些时候，这些工作需要手写复杂的SQL或者通过存储过程和触发器实现。手写复杂SQL对软件可维护性构成了相当大的挑战，随着SQL字数的变多，用到的嵌套和复杂语法增加，可读性和可维护性的难度是几何级暴涨。因此如何在实现功能的同时控制这些SQL的复杂度是一个很有价值的问题。而且这个问题同时涉及应用软件和数据库两个相对独立的体系，平行共管也是产生混乱的一大因素。

论如何直接用EF Core实现创建更新时间、用户审计，自动化乐观并发、软删除和树形查询（上）数据库并发，数据审计和软删除一直是数据持久化方面的经典问题。早些时候，这些工作需要手写复杂的SQL或者通过存储过程和触发器实现。手写复杂SQL对软件可维护性构成了相当大的挑战，随着SQL字数的变多，用到的嵌套和复杂语法增加，可读性和可维护性的难度是几何级暴涨。因此如何在实现功能的同时控制这些SQL的复杂度是一个很有价值的问题。而且这个问题同时涉及应用软件和数据库两个相对独立的体系，平行共管也是产生混乱的一大因素。

基于EF Core存储的Serilog持久化服务Serilog是 .NET 上的一个原生结构化高性能日志库，这个库能实现一些比内置库更高度的定制。日志持久化是其中一个非常重要的功能，生产环境通常很难挂接调试器或者某些bug的触发条件很奇怪。为了在脱离调试环境的情况下尽可能保留更多线索来辅助解决生产问题，持久化的日志就显得很重要了。目前Serilog支持文件和部分数据库持久化，文件日志的查找分析比较麻烦，而使用数据库持久化则会导致特定数据库依赖。既然有EF Core这种专门负责抽象底层数据库的持久化框架，为何不直接使用呢。怀着这样的心情去Nuget找了一

Abp框架，EF 生成迁移文件时，自动添加表和字段注释内容在使用 abp 框架，或者ef 的时候都会遇到一个问题，就是建实体后要将实体描述生成到数据库中，就需要手动去添加

假装我不帅

rider下ef core迁移安装Microsoft.EntityFrameworkCore.SqlServer包新建model新建dbContenxt

EF Core入门例子(以SqLite为数据库)测试环境：visual studio 2017.net core 2.1具体步骤如下：1 新增名称为EFCoreDemo的.net core控制台程序，版本选择.net core 2.1，项目不能放到带中文的目录下，不然到后面执行Add-Migration命令时会报如下的错误

Net Core中使用EF Core连接Mysql数据库Entity Framework Core的前身是微软提供并主推的ORM框架，简称EF，其底层是对ADO.NET的封装。EF支持SQLServer、MYSQL、Oracle、Sqlite等所有主流数据库。首先是使用时的几个模式的整理及其理解：

Ef Core花里胡哨系列(4) 多租户当然，我们要考虑设计问题，例如，切换Schema或者改变数据库时，Ef Core同样也会刷新改实体的缓存，所以，首次查询将会很慢，不适合大表。

Ef Core花里胡哨系列(10) 动态起来的 DbContext我们知道，DbContext有两种托管方式，一种是AddDbContext和AddDbContextFactory，但是呢他们各有优劣，例如工厂模式下性能更好呀等等。那么，我们能否自己托管DbContext呢？

Ef Core花里胡哨系列(1) SafeDelete、ReadOnly、Audit 安全删除、只读、审计等在软件设计中，软删除是一种常见的数据管理技术，用于标记和隐藏被删除的数据，而不是永久地从数据库中删除它们。软删除通常通过在数据表中添加一个额外的标志列（例如"IsDeleted"）来实现。当数据被删除时，该标志列被设置为指示删除状态的值（通常是true或1），而不是直接从数据库中删除数据记录。

Ef Core花里胡哨系列(7) 使用Ef Core也能维护表架构？我们这里指的并不是查询，而是利用Ef的迁移原理，生成可用的其它表架构操作的Sql。例如你想在Ef Core里建表，并且可能程序里有多个provider，那么写Sql将是一件痛苦的事情，我们就是利用Ef Core迁移时的操作，来为我们所用。