EntityFrameworkCore是微软官网提供的ORM框架，是轻量化、可扩展、开源和跨平台的数据访问技术框架，但是在.Net 开发圈的评论却褒贬不一。很多人认为EFCore 执行的效能比较差，很多复杂的查询场景很难实现，也有很多人认为，EFCore 开发简单，在中小型项目中，能够快速的实现业务逻辑。

  　　我个人认为，EFCore一直在不断的升级，社区反馈的问题也在逐一的去努力解决，EFCore应该是一个可以信任，可以在项目中放心使用的框架。特别是EFCore7.0出来后，提供的对JSON的支持，让我更加确信EFCore是一个优秀的ORM框架。我对其的一些优秀的功能进行总结：（1）首先，EFCore 的对象模型管理还是非常严谨，基本上将对象的关系和数据库的表的关系管理的非常到位，保证数据的纯净，并且可以进行连带的统一移除，这点是非常不错的；（2）其次，EFCore 提供了数据的变更管理，通过Migration工具将对象的变更和数据库的变更高效的进行了自动化的管理，特别是在产品软件开发过程中，提供了一键式部署提供了非常方便的支持。（3）EFCore 的对Linq 的支持力度是非常大的，能够快速的进行应用程序的开发。（4）EFCore 的后续版本对异步操作和性能提升方面，也做了很大的升级，（5）特别是EFCore7 版本支持了JSON功能，这个是对一些灵活的动态属性或者子表可以简化了数据库的变更，更好的适应非结构化数据存储。（6）种子数据的管理，方便产品型软件在程序首次启动时候，初始化一些原始的配置数据。…… 其实还有很多优秀的功能，我本次也不在熬述。

　　但EFCore 目前在一些查询和特殊的SQL语句的执行过程中，支持的不是特别好，性能也不是特别优秀。这个时候，我们需要引入另外一个ORM插件，Dapper，号称性能之王的ORM框架，在性能方面的确是非常非常优秀，功能也是很强大，支持的生态圈也是很丰富的。而且在.Net 开发圈内是非常受欢迎的。在这里，也不在介绍Dapper的优秀功能，可以参考官网：https://dapper-tutorial.net ，官网说明的非常清楚而且很详细。

　　当在进行全新软件架构选型数据处理层插件的时候，很让我头疼，是选择EFCore 还是Dapper 呢？经过一番折腾，我觉得两个插件其实是可以互相弥补彼此不足，发扬插件彼此的优秀能力，将两个插件高效融合在一起。基于这个思路，我开发了一个新的结合体数据访问层框架EFDapper，本着最简设计思路，在DbContext上面进行功能绑定，如下图，我们就可以将Dapper的 高效的查询功能和EFCore 进行了高效融合了。

 　　EFDapper 的使用是非常简单，就是EFCore 的功能和Dapper 的功能的合体，通过EFCore 的DbContext 的上下文，获取数据库连接信息，然后就可以扩展到Dapper 功能框架了，完美的结合了两个数据访问层框架。

　　目前EFDapper 框架还没有开发成熟，后续计划在两框架之间，可以开发一些优秀功能，也希望EFCore 和Dapper 框架越来越优秀。