【杂谈】关于EntityFramework（EntityFrameworkCore）的一些思考

关于EntityFramework（EntityFrameworkCore）的一些思考

以下EntityFramework简称EF。

Asp.net框架里里提供了一种将数据库语言直接糅合到程序语言C#中的方法：利用EF NuGet包，正确设置connection string之后可以直接以C#语言（大部分是Linq）来直接对数据库访问。这种方式省却了许多手动设置SQL语句、拼合字符串的时间，但笔者在最开始学习和尝试使用EF的时候却时常感觉到一知半解，因为EF功能强大，所以需要学习的内容特别多。

YouTuber iamtimcorey (Tim Corey) 在他的视频中提出了他的观点 —— 不建议使用EF，因为将一个自己不是特别理解的东西放在生产空间是十分危险的，尤其是当团队里所有人都对其理解不够深，它很容易成为一颗大雷。

另外，Tim也在他的教学系列中展开阐述了EF的问题，其阐述的方式也是十分的独到，直接从优势开始讲起，然后击溃其优势 ——

人们常常提到的EF的优势有两点:

• 快速开发

• 无需学习SQL语言

但这两点看似是EF的优势，其实在真正的生产环境中时常不攻自破：

• 快速开发
  • 使用EF+程序语言生成的SQL若不进行优化在执行效率上是比较低的，这就导致了虽然“开发”比较快，但是在投入到生产环境之前，需要花费较长的时间对其进行优化，其优势并不明显
• 无需学习SQL语言
  • 与上一条相呼应的，如果不懂得SQL语言的执行逻辑，何谈优化？
  • 虽然Linq语言与SQL不尽相同，但其背后的思想是相通的，在学习Linq的同时其实本质上也是在学习SQL语言

—— Tim Corey

笔者在学习用Asp.net的时候，跟随Youtuber Raw Coding搭建了一个个人博客网站，使用的是 .NET Core 3.1 MVC框架，其中博客存储的数据库Raw Coding使用了本地SQL Server，笔者则使用了MySQL，其中与数据库进行交互则采用的是EF Core。由于没法完全复制博主的流程，笔者整个EF的设置以及其和MySQL的交互都是Google + Baidu。现在想想也是十分的危险，因为数据库完全都不是自己在控制，这在网站真正上线的时候很可能会出现很大的问题。很多设置，包括Identity在内，都觉得是一知半解。

最终我参照Tim的建议使用了Dabber NuGet包，自己手动建立DataAccess对象，实现其依赖注入(Dependency Injection)，并且完整的替换了原来的Linq代码 —— 全套做下来其实也没有想象中那么难。

另外，Linq语言我个人十分喜欢，这也是为什么当我看到Raw Coding使用EF的时候，让笔者完全沉浸在了使用编程语言处理SQL连接的喜悦，但是冷静思考后的确发现，把对数据的掌控权交给任何其他人都是十分危险的，这也是为什么笔者最后选择放弃EF (以及EF Core) 的原因。