MyBatis-Flex 自定义枚举类型处理器问题解析

问题背景

在使用 MyBatis-Flex 框架时，开发者遇到了自定义枚举类型处理器（TypeHandler）失效的问题。具体表现为：当尝试通过 MyBatis 的标准方式配置默认枚举类型处理器时，MyBatis-Flex 在实体类扫描阶段就提前初始化了属性的 ColumnInfo，导致配置的处理器未能生效。

技术分析

问题本质

MyBatis-Flex 框架在启动时会扫描实体类并构建元数据信息（ColumnInfo）。对于枚举类型的字段，框架会在这个阶段就确定其类型处理器。然而，开发者通常是在应用上下文初始化阶段通过 TypeHandlerRegistry 来配置自定义的枚举处理器，这就导致了时序上的冲突：

1. MyBatis-Flex 先扫描实体类并初始化枚举字段的处理器
2. 然后开发者代码才执行，配置自定义的枚举处理器

与 MyBatis-Plus 的差异

在 MyBatis-Plus 中，这种配置方式能够正常工作，因为 MyBatis-Plus 的实体扫描和处理器初始化时序与 MyBatis-Flex 不同。MyBatis-Flex 更早地完成了字段处理器的绑定，导致后续的配置无法覆盖。

解决方案思路

针对这个问题，可以考虑以下几种解决方案：

1. 延迟初始化：修改 MyBatis-Flex 框架，使其支持枚举类型处理器的延迟绑定
2. 配置前置：寻找在实体扫描前就能配置类型处理器的方法
3. 注解覆盖：虽然不理想，但可以通过字段注解临时解决

最佳实践建议

对于希望保持枚举类纯净（不引入 ORM 框架依赖）的项目，推荐以下实践方案：

1. 实现自定义配置类：创建一个配置类实现 ApplicationContextAware 接口
2. 尽早获取 SqlSessionFactory：在 setApplicationContext 方法中立即配置类型处理器
3. 确保配置顺序：通过 @Order 注解或显式 Bean 依赖确保配置类先执行

框架优化方向

从框架设计角度，MyBatis-Flex 可以考虑：

1. 提供枚举处理器配置的专门接口
2. 支持处理器的动态更新机制
3. 增加对标准 MyBatis 配置方式的更好兼容

总结

MyBatis-Flex 在处理自定义枚举类型处理器时存在时序问题，这源于框架早期的实体扫描机制。虽然当前版本存在这一限制，但通过合理的配置方式和框架未来的优化，这一问题将得到解决。对于注重领域模型纯净性的项目，建议关注框架更新或采用临时解决方案，直到官方提供更完善的枚举处理支持。