使用Entity Framework Core时如何防止父子层级数据出现循环引用

首先给出问题中涉及的基础数据模型：

class Foo
{
   public int Id { get; set; }
   virtual Foo Parent { get; set; }
}

合法的层级结构为纯树状结构，不存在链路闭环：

a
  b
    c

非法的循环引用结构会在沿父节点遍历时回到已访问过的节点，形成闭环：

a
  b
    c
      a

核心疑问解答 #

能否通过将事务隔离级别设置为Serializable实现防循环？ #

完全不能。
Serializable是最高的事务隔离级别，仅能解决并发场景下的脏读、不可重复读、幻读问题，保证事务执行的结果和串行执行一致，但它完全不感知业务层面的层级链路逻辑。只要你更新节点父ID的操作符合外键约束，哪怕形成了循环引用，数据库也会正常提交，不会做任何链路合法性校验。

数据库侧创建触发器是不是最优方案？ #

不是最优，仅可作为兜底的最后一道防线。
触发器实现循环校验的逻辑本质是每次更新父节点时，递归遍历整条祖先链判断是否存在闭环，存在三个明显缺陷：

• 递归遍历的性能随层级深度增加线性下降，层级较深时开销很高
• 触发器逻辑和业务代码完全割裂，调试、迭代维护成本极高，很容易出现逻辑漏改导致的数据问题
• 不同数据库的触发器语法不兼容，迁移成本高
  如果一定要做数据库侧兜底，触发器可以用，但绝对不能作为唯一的校验手段。

推荐的落地方案 #

采用应用层校验为主，数据库层兜底为辅的两层防护即可：

• 应用层作为第一道防线：在新增、修改节点的父节点关联时，从待绑定的父节点出发，沿父引用向上遍历所有祖先节点，如果遍历过程中遇到当前正在操作的节点ID，直接判定为循环引用，终止提交流程。如果想进一步降低校验的数据库查询开销，可以给表增加一个Path字段，存储从根节点到当前节点的ID路径（比如c节点的Path为/a/b/c），校验时只需要判断待绑定父节点的Path中是否包含当前节点ID即可，无需递归查库。
• 数据库层作为兜底：如果不想写复杂的触发器，配合Path字段加简单的格式校验约束即可；如果需要强一致保障，再补充触发器做二次校验，避免应用层漏判导致脏数据入库。

是否需要为层级数据更换其他建模方案？ #

不是必须换，根据业务场景选择即可：

• 你当前用的邻接表（父ID引用）是最通用的层级建模方案，优点是节点增删改操作非常简单，适合层级深度不大、节点变动频繁的场景，只要做好前面说的循环校验，完全可以稳定使用。
• 如果你的业务有大量子树查询、层级很深，可以根据场景替换成其他模型：
  • 路径枚举：就是前面提到的存储Path字段，子树查询用前缀匹配即可，性能很高，缺点是移动节点时需要更新所有子节点的Path，适合节点位置变动少的场景
  • 嵌套集：通过给节点记录左值、右值标记所属范围，查询整棵子树性能极高，缺点是增删节点需要调整大量节点的左右值，适合读多写极少的场景
  • 闭包表：单独建关联表存储所有祖先-后代的对应关系和距离，查询灵活、性能好，缺点是需要额外维护关联表，存储开销更高，适合查询需求复杂的场景

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