Avo框架中非ActiveRecord资源使用KeyValueField的解决方案

背景介绍

Avo作为一款优秀的Rails管理面板框架，默认设计主要围绕ActiveRecord模型展开。然而在实际开发中，开发者有时需要创建不直接关联数据库表的资源，这时就需要使用框架提供的"手动定义资源"功能。这类资源通常继承自包含ActiveModel::Model等模块的基类，模拟ActiveRecord的部分行为。

问题现象

近期Avo框架的更新引入了一个关键变化：KeyValueField字段现在会调用*_will_change!方法来标记字段变更状态。这个改动对于标准的ActiveRecord模型完全透明，但对于手动定义的资源却可能引发问题，因为这些资源类默认不包含ActiveModel::Dirty模块的相关实现。

技术原理

ActiveModel::Dirty是Rails提供的一个重要模块，用于跟踪模型属性的变化状态。当调用attribute_will_change!方法时，Rails会将该属性标记为"脏"状态，表示该属性已被修改但尚未保存。KeyValueField依赖这个机制来正确处理字段值的变更，特别是当用户仅重新排序键值对而不修改内容时。

解决方案

对于自定义资源类，开发者可以采用以下两种方式解决兼容性问题：

1. 包含ActiveModel::Dirty模块： 最简单的解决方案是在基类中包含ActiveModel::Dirty模块，这将自动提供所有必要的变更跟踪方法。

2. 自定义实现变更方法： 如示例代码所示，可以为每个字段手动定义#{field_name}_will_change!方法。这种方法更轻量，但需要为每个字段单独实现。

class BaseCustomResource
  include ActiveModel::Model
  include ActiveModel::Dirty # 解决方案1
  
  # 或者解决方案2
  def self.field(name, **opts)
    attr_accessor name
    define_method(:"#{name}_will_change!") { send(name) }
  end
end

框架设计考量

虽然Avo当前主要针对ActiveRecord优化，但框架团队已经意识到对多样化数据源支持的重要性。未来的"资源适配器"架构将更好地支持API数据源、内存模型等非ActiveRecord场景。在此之前，开发者可以通过上述方案解决兼容性问题。

最佳实践建议

1. 对于简单场景，优先考虑包含ActiveModel::Dirty模块
2. 复杂场景下可以自定义变更跟踪逻辑
3. 保持对框架更新的关注，未来版本可能会提供更完善的非ActiveRecord支持
4. 在自定义资源中明确定义所有字段的访问器和变更方法

通过理解这些技术细节和解决方案，开发者可以更灵活地在Avo中使用各种类型的数据源，充分发挥框架的管理界面优势。