ef

面对ORM的选型，有些人是根据自己熟悉程度来评判，有些人是根据他人的推荐来抉择，有些人觉得都差不多，随便了。当自己要真正做选择的时候，以上的这些依据都无法真正说服自己，因为不同的业务需求，不同的团队构成都会造成选型的差异，而且特别大，这里谈一谈自己的选型。 1.1需求背景介绍 我所在的公司是做互联网产品，对性能有着 极致的要求 ； 后台人数也不算多，尽量人尽其用，技术水平呈 梯度分布 ； 因为产品需要长期维护，所以对 代码质量 要求非常高，必须做 评审和单元测试 ； 对技术的 可维护 性，可扩展性要求很高，因为资源有限； 因为资源有限，所以在 生产力和性能 之间需要做一个 平衡 ； 1.2需求分析 难点 　　我们知道没有完美的技术，鱼和熊掌无法兼得，所以我们必须择优录取，这里的复杂度在于你要对所选择的技术优缺点有一个 360度的环评 ，最好能展示各自 优缺点对比 一览图，最后依据数据来证明你的选择对的，是对团队和业务负责的。 现状 　　不知道你有没有呆过这样的团队： 选什么技术从不讨论，大伙各自闷声干，等干出来你才知道原来对方是用的IBatis.NET。 你是后面入职的，你只能在前人的基础上做维护，尽管你觉得这个技术不是最优的，但是你也无法了解当初为什么做这样的选择。 在入职后，没有规范的技术培训和规范，你一边Google一边编码一边骂娘。 　

前言 因为现在用.net core 开发新项目，过程中需要经常涉及到数据命令的迁移，今天分别整EFCore 的两种迁移数据库的方式 1 程序包管理器控制台 , Package Manager Console（PMC） -如果你用visual studio 开发建议使用PMC迁移方式，该方式是同时支持efcore和原先的ef 迁移的 2 命令行工具 ,Command line interface (CLI) -该方式适用于跨平台开发的时候进行迁移数据库的，也就是可脱离visual studio，比如你用vs code，或直接打开cmd控制台进行操作 1.下面先列出两种方式对比，然后再分用vs 和vscode分别详细说明 迁移命令描述 CLI命令 PMC命令 创建迁移：migrationname为迁移名称 dotnet ef migrations add migrationName add-migration migrationName 移除迁移(删除最近的一次迁移) dotnet ef migrations remove remove-migration 应用所有的迁移(使迁移文件应用到数据库) dotnet ef database update update-database 指定版本进行迁移 dotnet ef database update migrationName

数据注解特性是.NET特性，可以在EF或者EF Core中，应用于实体类上或者属性上，以重写默认的约定规则。 在EF 6和EF Core中，数据注解特性包含在 System.ComponentModel.DataAnnotations 命名空间和System.ComponentModel.DataAnnotations.Schema命名空间下。 这些特性不仅仅适用于EF，同样适用于ASP.NET MVC以及数据控件。 System.ComponentModel.DataAnnotations.Schema Attributes [Table(string name,[Schema = string])] name 想要定义的表名称 Schema 可选参数，数据库的模式名称 [Column(string name,[Order = int],[TypeName = string])] name 列名 Order 可选参数，列的顺序，从0开始，注意必须为每个属性都设置（不可重复）才能生效、 TypeName 可选参数，列的数据类型 [NotMapped] 不将该属性映射到数据库的列 [ForeignKey(string name)] 设置外键3种方式 [Index(string name)] 为列创建索引 IsClustered用来创建聚合索引， IsUnique用来创建唯一索引。

CodeFirst 工作流程 创建或修改领域类-->使用数据注解或者Fluent API来配置领域类-->使用自动数据库迁移技术或者基于代码的数据库迁移技术来创建数据库。 CodeFirst默认约定 约定就是一系列的默认规则，通过这些规则，在使用EF Code-First的时候，可以自动的基于你的领域类配置概念模型。默认约定的命名空间：System.Data.Entity.ModelConfiguration.Conventions; ①schema(模式) 默认情况下，EF会为所有的数据库对象，创建dbo模式名称。 注：dbo--database owner 数据库所有者，当你在数据库新建对象时，默认所有者为当前登录账号，当用其他账号登录时，必须指定 所有者.对象 才能调用，为了避免麻烦可以将对象的所有者指定为dbo，这样不管谁调用，使用dbo.对象就可以了。 ②Table Name(表名) EF默认为实体类创建的表名为实体类+s，如Person类的表名：Persons ③Primary Key Name(主键名) EF默认将Id属性或实体名+Id（不区分大小写）设置为主键。 ④Foreign Key Name(外键名) Person类主键为Id，有一个Student类型的属性S，Student主键为StuId EF会首先查找Person类中有无StuId属性，有的话设为外键

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> https://github.com/loresoft/EntityFramework.Extended 也可以在nuget上直接安装这个包，它的说明有点过时了，最新版本已经改用对IQueryable<T>的扩展，而不是DbSet<T>（已经标记为弃用）,所以跟我一样有隔离癖好的就可以大胆使用了。下面介绍如何批量删除、更新、查询。 批量删除 本来我们需要这样删除 //EF原生的删除需要先取出entity然后remove context.Remove(context.Users.First(u=>u.Key==xxx); //如果要删除更多 foreach ( var user in context.Users.Where(u => u.FirstName == "firstname" ).ToList()) { context.Remove(user); } 本来一句sql可以解决的问题，变得复杂了。 使用ORM是为了跟sql尽量的解耦，并且能在编译时检查出更多的错误，但是上面的写法让人堵的慌，如果你也有这种感觉下面的写法是不是就是你脑子里想要的东西呢。 ----引用EF Extend Libary后删除只需要一次就完成了，效率高了很多，也不需要太多的连接资源，使用更方便了 //delete all users

延迟加载只对关联属性（Navigation Property）有用，普通属性没有这个东西。 延迟加载是一条一条的读取属性，调用一次，读取一次。 条件： context.Configuration.ProxyCreationEnabled = true;(默认为true) context.Configuration.LazyLoadingEnabled = true;(默认为true) POCO类为public，导航属性要加virtual修饰符。 注：POCO---Plain Old CLR Object，指那些不包括INSERT、DEL等数据持久化操作及任何业务逻辑的原始类。 原理分析： EF动态的生成了实体类的子类，然后override了virtual属性（所以不加virtual的话就得不到属性值） 优点：避免一次性加载所有数据，提高了加载的速度。 缺点：用一次加载一次，提高了数据库服务器的压力。 所以，当数据库的数据越多，我们用到的数据越少时，推荐使用延迟加载，反之使用预先加载。 来源： https://www.cnblogs.com/1016391912pm/p/12037869.html

1.EF基本的CRUD（增删改查）流程 2.EF的工作过程简析 EDM--Entity Data Model--实体数据模型 概念模型 ： EF通过领域类，上下文类，默认约定和配置构建概念模型。 存储模型 ： EF为底层数据库架构构建存储模型。在代码优先方法中，根据概念模型进行推断来构建。在数据库优先模式中，根据目标数据库进行推断来构建。 映射 ： EF包括的映射信息，表示概念模型是如何映射到数据库架构（存储模型）。 查询 保存 EF API在调用SaveChanges()方法时根据实体的状态推断INSERT，UPDATE和DELETE命令。ChangeTrack会在执行操作时跟踪每个实体的状态。 来源： https://www.cnblogs.com/1016391912pm/p/12024166.html

ORM基础知识 一.什么ORM？ ORM是Object Relactional Mapping的缩写，即对象关系映射，是将关系型数据库中的数据库结构映射成对象，就可以通过面向对象思想编程。 二.常用的ORM框架有那些？ Dapper、Entity Framework（EF） 三.常用的ORM框架之间的区别是什么？ Dapper都是轻量级的框架 EF都是重量级的框架 来源： https://www.cnblogs.com/zlp520/p/12021899.html

由于需要新增的XML数据较多，可以另起项目，将新增的XML数据复制到原来的EF 来源： https://www.cnblogs.com/Cengjianwei/p/11978054.html

前言 随着.NET Core 3.0的发布，EF Core 3.0也随之正式发布，关于这一块最近一段时间也没太多去关注，陆续会去对比之前版本有什么变化没有，本节我们来看下两个查询。 分组 我们知道在EF Core 3.0版本之前，对于分组查询是在客户端评估，也就是说在内存中操作，在EF Core 3.0版本后对于分组查询可以翻译成SQL在数据库进行，但是事实情况真的是这样吗？接下来我们来看下吧，如下给出代码例子。 public class EFCoreDbContext : DbContext { public EFCoreDbContext() { } public DbSet<Blog> Blogs { get; set; } public DbSet<Post> Posts { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) => optionsBuilder.UseSqlServer(@"Server=.;Database=EFTest;Trusted_Connection=True;"); } public class Blog { public int Id { get; set; } public string Name { get;