MyBatis-Flex 中 UpdateListener 修改属性无效问题解析

问题背景

在使用 MyBatis-Flex 框架进行开发时，开发者可能会遇到一个特殊场景：在 UpdateListener 中对实体属性进行加密处理时，发现修改后的属性值并未生效。这个问题在 SetListener 和 InsertListener 中表现正常，但在 UpdateListener 中却出现了异常。

问题现象

具体表现为：当开发者尝试在 UpdateListener 中修改实体属性时，最终生成的 SQL 更新语句中的参数值仍然是调用监听器之前的原始值，而不是经过监听器修改后的值。

问题根源

经过深入分析，发现问题的根源在于 MyBatis-Flex 的更新机制设计。当使用 UpdateEntity.of() 方法进行局部更新时，框架会生成一个代理对象 UpdateWrapper。这个代理对象在设置属性时会先将变更的属性缓存到 com.mybatisflex.core.update.ModifyAttrsRecordHandler#updates 中。

这种设计导致了一个关键行为：在业务逻辑中直接修改入参对象的属性时，由于框架已经缓存了原始变更属性，后续对对象属性的修改不会反映到最终的 SQL 更新中。

与 Insert 操作的对比

值得注意的是，这个问题在 Insert 操作中并不存在。这是因为 MyBatis-Flex 在构建插入 SQL 参数时，会通过 getter 方法重新获取属性值。具体实现位于：

1. com.mybatisflex.core.table.TableInfo#buildInsertSqlArgs
2. com.mybatisflex.core.table.TableInfo#getPropertyValue

这种设计保证了在 InsertListener 中对属性的修改能够正确生效。

解决方案建议

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

1. 使用完整的实体更新：避免使用 UpdateEntity.of() 进行局部更新，转而使用完整的实体对象进行更新，这样可以绕过代理对象的属性缓存机制。

2. 在业务层提前处理：在调用更新方法前，先在业务层完成所有属性的修改，包括加密等处理，然后再将处理后的对象传入更新方法。

3. 自定义 UpdateWrapper：如果需要保持局部更新的高效性，可以自定义 UpdateWrapper 实现，在构建 SQL 前手动处理需要修改的属性。

框架设计思考

这个问题反映了框架在局部更新和完整更新之间的行为差异。从设计角度看，这种差异是有意为之的：

1. 性能考虑：局部更新通过缓存变更属性避免了不必要的属性访问，提高了性能。

2. 明确性：强制开发者在调用更新方法时就明确指定要更新的字段，避免意外更新。

3. 一致性：确保更新操作只影响明确指定的字段，防止数据不一致。

最佳实践建议

基于这个问题的分析，建议开发者在实际项目中：

1. 明确区分局部更新和完整更新的使用场景。

2. 对于需要监听器干预的属性修改，优先考虑在业务层完成处理。

3. 如果必须在监听器中处理，可以考虑使用完整实体更新或者自定义更新逻辑。

4. 在团队内部建立统一的属性处理规范，避免因不同开发者的实现方式差异导致的问题。

通过理解 MyBatis-Flex 的这种设计理念和行为特点，开发者可以更合理地使用框架提供的各种功能，编写出更健壮、更高效的代码。