EntityFramework6与EFCore3.1如何自定义scaffolding映射NodaTime类型？

核心结论 #

EF6和EFCore 3.1都支持自定义脚手架流程，完全可以实现将SQL Server数据库类型自动映射为NodaTime对应的CLR类型，没有技术障碍，只是两个版本的扩展机制完全不同。你之前查的公开资料找不到具体实现，本质是大部分早期回答只讲了改T4模板的浅层自定义，没讲反向工程核心流程里的类型替换逻辑，自然不会有对应的代码示例。

EFCore 3.1 具体实现方式 #

EFCore 3.1的反向工程是基于依赖注入的模块化流程，核心扩展入口是IScaffoldingModelFactory：这个组件负责把从数据库读出来的表结构元数据转换成EF的实体模型，后面生成实体类、输出代码文本的所有逻辑，都是基于这个阶段产出的模型做的。相比直接改T4模板在文本层面替换类型名，在这个阶段改CLR类型能保证全流程的一致性，不会出现模型元数据和实际生成的属性类型对不上的问题，省得后面踩迁移、读写的坑。

实现步骤 #

• 引入必要依赖：项目内安装对应3.1版本的Microsoft.EntityFrameworkCore.SqlServer、NodaTime NuGet包。
• 自定义Scaffolding工厂，继承内置的SqlServerScaffoldingModelFactory类，重写类型解析逻辑：
  • 碰到列的数据库类型是date的时候，把对应实体属性的CLR类型设为NodaTime.LocalDate，一定要跟着列的可空性走——比如数据库列允许为NULL，就生成LocalDate?类型，不然会出非空值类型对应可空列的编译错误
  • 碰到列的数据库类型是datetime/datetime2的时候，把对应实体属性的CLR类型设为NodaTime.Instant，同样同步好可空性标记
• 实现设计时服务注册接口IDesignTimeServices，在配置方法里把默认的IScaffoldingModelFactory替换成你自己写的自定义工厂。这样EF工具在执行Scaffold-DbContext、dotnet ef dbcontext scaffold命令的时候，才会加载你的自定义逻辑，不然改了工厂也白搭，工具根本不会认。
• 别忘了补运行时的配置：脚手架只是生成实体类的代码，你还要在模型配置里给这些NodaTime类型加对应的类型映射和值转换器，告诉EFCore怎么在NodaTime类型和SQL Server底层存储的类型之间做双向转换，不然就算脚手架生成的代码全对，运行的时候也会因为不认类型读不出数据。

别只在代码文本输出的阶段改类型名，那样EF存的模型元数据还是原来的DateTime类型，和实际生成的NodaTime类型完全脱节，后面不管是生成迁移还是读写数据都会出莫名其妙的问题，排查起来特别麻烦。

EF6 具体实现方式 #

EF6的脚手架完全靠内置的T4模板跑，没有提供EFCore那种强类型的扩展工厂，改起来反而更直接：

• 找到项目里EF反向工程生成的两个核心T4模板：一个是生成实体类的，一个是生成实体映射配置的
• 直接改模板里的类型解析分支：原来碰到date类型返回System.DateTime的逻辑，改成返回NodaTime.LocalDate；原来碰到datetime/datetime2返回System.DateTime的逻辑，改成返回NodaTime.Instant
• 在T4模板的头部配置里，把NodaTime的命名空间加到自动生成的using列表里，省得每次生成完实体类还要手动补引用
• 别忘了加EF6的运行时适配：EF6原生根本不认NodaTime的类型，你得通过自定义类型描述符或者映射配置，搭好NodaTime类型和底层System.DateTime存储类型的转换逻辑，不然运行的时候直接报类型不匹配。

常见踩坑提醒 #

• 类型映射一定要和数据库列的可空性严格对齐，不然生成非空值类型对应可空列的代码，编译都过不了
• 自定义脚手架只影响生成代码的类型，必须同步配置运行时的类型转换规则，别以为生成完代码就完事了
• 改类型逻辑的时候别硬编码表名、列名做判断，就根据列的数据库类型做匹配，这样换个表、换个库也能通用，不用每次改脚手架逻辑

内容的提问来源于stack exchange，提问作者OldShaterhan