元数据映射的两种实现途径：代码生成 vs 反射编程

把关系-对象映射的细节浓缩进元数据后，让这份元数据真正驱动运行代码主要有两条路。代码生成：写一个程序，输入元数据、输出映射实现类的源代码，这些代码在构建阶段（通常紧邻编译前）生成，看起来和手写的没什么两样，但不应该被手工编辑、也不需要纳入源代码控制——好处是调试时更直观，能在调试器里清楚看到实际运行的代码，作者本人更偏爱这条路，认为对水平一般的开发者更友好；代价是缺乏动态性，映射一旦要改，至少要重新编译、重新部署相关部分。反射编程：把方法和域当成数据，运行时从元数据文件里读出域/方法名字，动态调用（比如动态找到并调用setName）来完成映射——好处是动态，改一下映射数据文件，现有的类立刻就能用上新元数据，甚至可以在程序运行期间监听某种特殊中断来触发重新读取；作者虽然承认反射非常适合数据库映射这个场景，却仍然通常不建议用它，主要顾虑不是速度（反射调用本身慢，但架在同样慢的远程SQL调用之上，这点损耗未必是大问题，具体影响需要实测），而是反射代码往往很难调试。两种方式都不太好调试，最终选哪个很大程度上取决于开发团队对”生成代码”和”反射代码”各自的熟悉程度。

结构图：

flowchart LR
  A["元数据驱动映射的两条路"] --> B["代码生成<br/>构建期生成源码<br/>调试直观但改动需重新编译部署"]
  A --> C["反射编程<br/>运行时动态调用<br/>改元数据即生效但难调试"]