一步步学习EF Core(3.EF Core2.0路线图)
这几天一直在研究EF Core的官方文档,暂时没有发现什么比较新的和EF6.x差距比较大的东西.
不过我倒是发现了EF Core的路线图更新了,下面我们就来看看
今天我们来看看最新的EF Core 2.0路线图
E文好的移步:https://github.com/aspnet/EntityFramework/wiki/Roadmap#ef-core-20
嗯,我就直接翻译了,翻译的不好请各位大神原谅..
以下是EF Core的路线图。请注意，功能计划可能会更改。
这跟任何项目一样，很难准确地预测什么时候会确定。
即使如此，我们也认为尽可能公开和透明地对我们的计划非常重要，
这样我们的用户就可以获得正确的期望并相应地制定自己的计划。
1.时间表
EF Core的更新计划与.NET Core和ASP.NET Core时间表同步,如下:
| 发布版本 | 发布季度 |
|---|---|
| 2.0- preview1 | 2017年第2季度 |
| 2.0- preview2 | 2017年第2季度 |
| 2.0 | 2017年第3季度 |
| 2.1 | 2017年第4季度 |
值得注意的一点是,在ASP.NET Core的路线图中,全新的SignalR将在ASP.NET Core2.1版本发布
2.积压的内容
因为EF Core是一个新的代码库，所以在Entity Framework 6.x中存在一个功能并不意味着会在EF Core中实现。
具体区别请移步:比较EF Core和EF6.x
我们提供了我们认为重要但还没实施功能列表。仅供参考
3.关键的ORM功能
下面是微软开发团队认为需要的东西，微软爸爸觉得..嗯..EF Core是可以向所有人推荐的EF版本。
但是在实现下面这些功能之前，虽然EF Core对于许多应用场景来说是一个有效的选择（特别是在.NET Core的平台上，因为EF6.x不起作用..(懵比脸)..），
但是对于许多应用来说，缺少下面这些功能将使EF6.x是目前更好的选择。
嗯..下面就是微软爸爸觉得需要,但是还在研发 或者斟酌的东西:
3.1Query(查询)
- 改进的Linq翻译将使更多的查询成功执行，使得更多的逻辑在数据库（而不是内存中）中进行查询，从而减少不必要的数据库访问。(这一项已经在2.0预览版本完成了很多.)
- 延迟加载功能。
- 对于不在模型中的原始SQL语句查询,允许使用原始SQL语句查询来填充不在模型中的类型（通常用于非规范化的视图模型数据）。
3.2数据库图形化管理
- 用于DBFirst的Visual Studio向导，允许您在从现有数据库创建模型时,可视化地配置连接，选择表等。
- 从数据库更新模型允许以前从数据库逆向工程的模型将随着您对架构的更改而刷新。
3.3Modelling(实体模型)
- 复数/值类型是不具有主键的类型，用于表示实体类型上的一组属性。这通过EF Core 2.0中支持的所有类型和表解决。其中一部分已经在预览1完成了
- 存储过程映射,允许EF使用存储过程来保存对数据库的更改（
FromSql已经提供了对使用存储过程进行查询的良好支持）。 - 改进的视图映射,允许EF自动从数据库逆向工程视图或使用迁移维护它们(DBFirst)。
4.高优先级的功能
-
实体模型
- 更灵活的属性映射，如构造函数参数，get / set方法，属性包等。
- 简单的类型转换，如string => xml。
- 多对多关系没有连接实体。可以与连接实体建立多对多关系。
- 关系数据库的替代继承映射模式，例如每种类型的表（TPT）和每个具体类型TPC的表。
- 空间数据类型，如SQL Server的
geography＆geometry。 - 可视化模型图以查看CoreFirst的模型图形。
-
CRUD
- 初始化数据允许数据库在迁移过程中自动填充初始数据。
- ETag式并发令牌支持提供了统一的编码模式，用于管理与模型配置无关的并发性。
- 贪婪加载,允许在查询实体时始终检索默认的相关数据集。
- 过滤加载,允许加载相关实体的一个子集。EF Core 2.0 预览版本中的全局查询过滤器已经解决了这一点
- 简单的命令拦截提供了在发送到数据库之前/之后读取/写入命令的简单方法。
-
更多的数据库支持
- Azure Table Storage
- Redis
- 其他非关系型数据库
-
平台
- 通用Windows平台（UWP）目前适用于本地开发，但是与.NET Native工具链中的.NET Native工具链存在问题，EF和.NET Native团队正在努力解决。
- Xamarin在使用EF core还未完全测试.
5.EF Core 2.0（还开发中...）
预览1版本已完成的主要功能：
- 简化服务和提供商的架构（＃7457） - 允许EF Core及其提供商以更简单和更有效的方式使用DI。(依赖注入~)
- Group Join改进（＃2546） - 此工作改进了为Group和Join所生成的SQL语句。
- 改进的LINQ翻译（来自于GitHub上的各种问题） - 允许更多的查询成功执行，更多的逻辑在数据库中执行（而不是内存中），从而减少不必要地从数据库查询数据。
- EF.Functions.Like（）（＃2850） - 允许将通配符的字符串匹配转换为SQL或在内存中进行匹配。
- 拥有的实体和表分割（以启用复杂类型和/或值对象模式）（＃246） - 允许映射类型不具有自己的身份，但始终依赖于其他对象，并将它们映射到与其父对象相同的表。
- 全局查询过滤器（＃5774） - 允许为实体类型配置垂直过滤器。然后，此过滤器将适用于所有查询，包括贪婪加载（即
Include()）。 - 上下文池（＃6923） - 通过使
DbContext实例可以重用而不是始终从头开始创建，从而提高性能。(重要!!!重要!!!重要!!!) - 手动编译查询（＃8449） - 允许查询表达式与代理相关联，从而可以只编译一次但执行多次，从而不会导致增加高速缓存键计算和高速缓存查找的成本。
- 将SQLite提供程序移动到SQLitePCL.raw（Microsoft.Data.Sqlite＃21） - 这为Microsoft.Data.Sqlite提供了一个更强大的解决方案，用于在不同平台上分发本机SQLite二进制文件。
- IEntityTypeConfiguration（＃2805） - 允许一个实体的Fluent API配置到一个类中。
下面是期望完成的其他功能：
- 每个模型＃7166只有一个提供商） - 显着增加了供应商如何与模型进行交互，并简化了惯例，注释和流畅的API如何与不同的提供商合作。
- 综合测试和诊断（＃218，＃7217等）
- 应用程序洞察集成（＃8272） - 有助于改进和调试应用程序的诊断信息,使他变得更容易访问。
下面是取得了一些进展但有无法按时完成风险的内容：
原来考虑加入,但没有进展，基本上要推迟的内容：
- 用于非实体类型的原始SQL查询（＃1862） - 使用不在模型中的类型执行具有临时映射的查询。
- Azure搜索集成 - 允许您在查询数据时使用Azure搜索中的搜索索引。在数据更新操作期间透明地同步索引数据。
- 从数据库更新模型（＃831） - 允许您逐渐更新以前从数据库反向设计的模型，并更改了对数据库模式所做的更改。这允许您更新模型以匹配当前模式，而不会丢失在反向设计后手动对模型进行的任何更改。
- 生命周期挂钩（＃626） - 包括创建实体（
ObjectMaterialized从EF6.x），数据库命令拦截，连接打开时运行附加命令的事件。 - 简单的日志记录API（＃1199） - 我们想要一个简单的方法来记录正在执行的SQL（就像
Database.Log从EF6.x）。我们还需要一种简单的方法来查看正在记录的内容。 - GroupBy翻译＃2341 - 允许使用GroupBy（）运算符翻译LINQ查询，该项目用于汇总要使用GROUP BY转换为SQL查询的函数。
原来考虑加入,但是至今没有加入计划的任务：
- 基于ODBC的提供程序（＃7432） - 这将允许为具有ODBC提供程序的数据库（但可能没有特定于数据库的ADO.NET提供程序）创建一个EF Core提供程序。
其实从路线图可以看出来,微软爸爸的整个构想是相当好的.
而且听取了很多社区中好的意见和建议(每个功能后面的"#一串数字",就是Github的Issues)
嗯,从EF4.0用EF一直到现在,也算是死忠粉了.最后说一下我个人比较关注的几个功能.
1.上下文池（＃6923）,这个太TM及时了..泪流满面啊..想想每次被人吐槽的初始化产生的性能损耗..想想..竟然还需要预热启动..,是不是有种拨开云雾见太阳的感觉..
2.EF.Functions.Like（）（＃2850） - 这个目前是只加入了like,后期还要加入更多的数据库函数.大大增强了代码可读性和效率
