【ASP.Net】老生常谈，ASP.Net + EF6 对接

序

众所周知，.NET+EF6是没有直接支持MySQL的，为了集成MySQL并且愉快的使用EF的DbContext操作，需要自己解决环境问题。
我的MySQL是8.0CE，VS2019 Community；项目选的.NET Framework 4.5.2（4.5以上基本是兼容的，.Net Core2.0下除了没有可视化操作外，其他一致）

主要依赖

MySql.Data (>= 8.0.19)
EntityFramework (>= 6.2.0)

必装环境

mysql-connector-net-8.0.19.msi
mysql-for-visualstudio-2.0.5.msi

注意，mysql-connector-net 必须与MySQL.Data 版本一致，否则无法使用。

开发时

通过新建ADO.Net 对象进入EF配置，指定链接字符串和DbCondext对象名称即可；
创建方式有两类，来自数据库创建模型 或 来自CodeFirst方式。

Code First

通过代码方式定义数据库表结构。EF支持两种方式，空的EF设计器，或空的Code First模型。
这两种方式都适用于项目初建时，通过先设计程序的数据模型对象，再通过EF自动建表。个人觉得开发层面来说是比较优秀的思路，开发能专注到对象模型的构建上，而不需要过多关注怎么去满足数据库的结构化存储问题。但毕竟关系库、结构化存储还是开发基本功，所以稍微大规模一点的项目，一般应该没有应用这种方式。

基于数据库创建

这种场景就和常规的开发流程一致了，先构建数据库，再写代码。
也包括两种模式，EF设计器方式会得到一个通过数据库进行自动生成的 edmx模型，带有一个可视化工具，生成的文件统一打包放在edmx上，在VS中可以展开为具体的每个数据表对象定义。这种方案给提供了可视化操作，包括构建外键关系、添加字段等操作均可直接在模型上编辑，然后使用 migration 工具同步到数据库。在数据库有变更时，也可以直接在EF设计器上进行刷新可以完成同步。
Code First模型方式的差异是没有edmx文件,新生成的文件主要包括 DBContext.cs 和各个表的数据结构。相比于Edmx方式，使用的便利性等都有所下降，但好处是熟悉代码的人可以很快排查到问题。

踩坑

以上提到两种方式，我是采用第二种，基于数据库创建。一开始考虑使用Edmx方式，便于同步更新，但发现编译成功后运行报错，提示找不到表。查了详细的错误信息，发现调用表名的语句里 数据库名称 被拼接了两次。

• 初步考虑的解决方式是改配置文件里的ConnectionString，去掉表名定义，但是很显然想多了，如果ConnectionString不包括DB名，会直接报错“未指定数据库”。
• 所以从edmx的生成文件中考虑入手，但翻遍了代码，没有找到相关的配置。每个Table对象定义也检查过，并没有写成 [DB].[Table]的定义 。
• edmx有一个配置文件，唯一找到的有定义DB名称的配置是 schema， 去掉这个属性或写空字符后，报错变成了找不到表 [DB].[xxxEntities].[Table]； xxxEntities是我定义的DbContext名称。

我猜可能需要更进一步的了解EF For Mysql的工作原理才行。如果有大佬踩过这个坑，也感谢指点。

所以相比下，在没解决上边的问题前，采用第二种方案可以规避这个问题。 其实第二种方案自动生成的每个Table对象也会在[Table ("")]注解上加上表名，所以不处理直接调用也会出现一样的问题。但是，第二种方式生成的代码不需要与EF设计器文件同步，直接修改是可以的。

运行时

额外的多一个坑是，通常来讲编译文件发布后，应该是能够异地移植的。但是当我移植到了服务器上后，报错提示缺少 mysql Connector，是需要安装同版本的connector的。
暂未测试是否通过带着connector的相关dll发布就可以解决（应该是，后续再更新测试情况）

参考资料

https://blog.csdn.net/qq_34202873/article/details/105494723 这篇蛮好的