杨中科 EFCORE 第四部分 命令详解56-61
Migrations
深入研究Migrations
1、使用迁移脚本，可以对当前连接的数据库执行编号更高的迁移，这个操作叫做“向上迁移” (Up)，也可以执行把数据库回退到旧的迁移，这个操作叫“向下迁移(Down）
2、除非有特殊需要，否则不要删除Migrations文件夹下的代码。
3、进一步分析Migrations下的代码。分析Up、Down等方法。查看Migration编号。4、查看数据库的_EFMigrationsHistory表: 记录当前数据库曾经应用过的迁移脚本，按顺序排列
示例：
程序结构
Person 类
PersonConfig
MyDbContext
主程序类
运行：
此时查看 Migrations下生成的文件
发现文件中有两个 方法 分别是 up 和 down
up 方法是创建过程 向上迁移
down 是向下迁移 up创建了表 ，会滚的话 就是删除表
此时若是增加一列
执行命令（在实际开发中，不能操作过于频繁）
此时，Migrations文件中，新增了一个脚本 up方法中的内容也发生了改变，是增加一列
（文件前面的编号内容也在增大）
此时的向下迁移 down 方法
则是删除该列
执行 Update-Database
查看数据库内容
查看EFMigrationsHistory
ProductVersion ： EFCORE 版本
MigrationsId : 显示数据库都执行了哪些脚本
这个表 是由EFCORE 维护
若估计删除表中一行记录
然后执行update-database
出现报错信息
列重复。
数据库其他迁移命令
Migrations其他命令
1、Update-Database XXX把数据库回滚到XXX的状态，迁移脚本不动
2、Remove-migration删除最后一次的迁移脚本
3、Script-Migration
生成迁移SQL代码。有了Update-Database 为什么还要生成SOL脚本。
可以生成版本D到版本F的SOL脚本:Script-Migration D F
生成版本D到最新版本的SOL脚本: Script-Migration D
Update-Database XXX
示例：
删除数据库
执行 Update-Database
此时数据直接到 AddHeight 版本
使用 Update-Database xx 尝试还原到上一个版本
刷新数据库，发现还原成功
表中记录也减少一条
再次 执行 删除数据库操作。
此时需要达到 只执行到Init 状态，不执行到 add height
测试成功
Remove-migration
为了防止不小心 删除了 破环了前后关系，最好不要手动删除迁移脚本
而是使用 Removing 命令 删除最近一次记录
Script-Migration
此时在编辑器 中打开了一个sql文件
这样的目的 是在项目上线后，修改数据时，能更直观的看到如何修改得数据库 ，防止不小心的操作破坏生产环境
生成中间版本 到某个版本的迁移脚本
sql脚本
再把该代码 复制到数据库中运行
结果：
Script-Migration D 生成某个版本到最新版本的数据迁移记录
EFCORE 反向工程
反向工程
I、根据数据库表来反向生成实体类
2、Scaffold-DbContext ‘Server=.;Database=demol;Trusted_Connection=True;MultipleActiveResultSets=true’
Microsoft.EntityFrameworkCore.SqlServer
开发一个项目，但这个项目已经有了一些数据库。这个时候可以考虑使用反向工程
示例：
新建数据库
新建表
命令输入执行
此时项目中自动生成了 Dbcontext 和 Person 类
注意
1、生成的实体类可能不能满足项目的要求，可能需要手工修改或者增加配置。
2、再次运行反向工程工具，对文件所做的任何更改都将丢关
3、不建议把反向工具当成了日常开发工具使用，不建议DBFirst.
FECORE 底层如何操作数据库
Know How
1、为什么需要了解EF Core底层原理
框架是简化操作，不是让程序员变成傻瓜
EFCORE 底层就是靠 ADO.NETCORE来操作的
原理：
查看生成的SQL语句
1、SOL Server Profiler(收费版才有)查看SOLServer数据库当前执行的SQL语句。
查询窗口执行过的sql 语句 在SQL Server Perfiler 就能监控到
代码方式
2、var books = ctx.Books.Where(b =>b.Price > 10 b.Title.Contains(“张”));
EF Core把C#代码转换为SQL语句的框架
EFCORE 有哪些做不到的事情
Why
1、C#千变万化;SQL功能简单。存在合法的C#语句无法被翻译为SQL语句的情况
var books = ctx.Books.Where(b => IsOK(b.Title));
private static bool IsOK(string s)
{
return s.Contains("张");
}
示例：
语句成功被翻译成为sql
修改代码
完全可以编译通过的合法sql 语句
报错，该Linq 表达式 无法被翻译为sql
sqlseverprofiler中也没有记录
通过代码查看EFCORE 生成的SQL
Why
不是有SQL Server Profiler了吗?
SQL Server Profiler 是查看服务器上所有的SQL 语句，多人操作。
方法1: 标准日志
public static readonly ILoggerFactory
MyLoggerFactory
= LoggerFactory.Create(builder => builder.AddConsole(););
optionsBuilder.UseLoggerFactory(MyLoggerFactory);
示例：
nuget 查找 logging console
编写代码
运行：
方法2:简单日志
optionsBuilder.LogTo(Console.WriteLine):
可以自己写代码过滤一些不需要的消息
示例：
运行结果：
只输出跟sql语句相关的东西
运行结果：
好处：可以看到更细节的东西，不用引入logging的框架
方法3: TOQUERYSTRING
1、上面两种方式无法直接得到一个操作的SQL语句，而且在操作很多的情况下，容易混乱。（需要精确查看自己想看的sql）
2、EF Core的Where方法返回的是IQueryable类型, DbSet也实现了IQueryable接口。 IQueryable有扩展方法ToQueryString0可以获得SQL
3、不需要真的执行查询才获取SOL语句:只能获取查询操作的。
示例：
运行：
【总结】
写测试性代码，用简单日志; 正式需要记录SQL给审核人员或者排查故障，用标准日志;开发阶段，从繁杂的查询操作中立即看到SQL，用ToQueryString()。