在实体框架中创建嵌套实体的层次结构

Question

我正在尝试在实体框架中创建一个分层表示,在搜索之后我似乎找不到很多关于这个主题的内容.

前提:我正在开发一个反向链接监控工具,我可以在其中粘贴一堆URL以查看它们是否指向特定域.如果是这样,我想从列表中删除它们并将它们存储为顶级(第1层)反向链接.找到并删除直接链接到URL的所有反向链接后,我想运行列表中剩余的反向链接,看看它们是否指向新创建的顶级反向链接列表中的任何URL,以及指向顶级反向链接的那些,将它们存储为第2层反向链接.然后搜索第3层反向链接,依此类推,直到检查完整个列表.

我有一个网站实体,其中包含用于第一次运行导入反向链接列表的Url.找到的那些被移动到列表中,并且在第二次循环时使用它们的URL,依此类推.

我最初在网站实体中为链接的每个"层"创建了一个单独的属性,但这似乎不是非常有效,因为在尝试渲染层次结构时,代码必须循环遍历每个层并重新匹配URL从下面的层重新创建实际的链接结构.

最终目标样本:

所以我相信我应该创建一个单独的"反向链接"模型,并让每个反向链接实体存储其下面的反向链接列表,然后在尝试查看反向链接层次结构时,只需执行一个简单的循环,并遍历每个子链接反向链接实体.

反向链接实体的示例如下:

public class Backlink
{
    public int BacklinkID { get; set; }
    public string Url { get; set; }
    public string AnchorText { get; set; }
    public string LinksTo { get; set; }

    public int PageAuthority { get; set; }
    public int PageRank { get; set; }

    public virtual ICollection<Backlink> Backlinks { get; set; }
}

我编写了实际经过的代码并检查每个反向链接的HTML,以查找反向链接是否指向每个特定的URL,所以现在我试图找出存储结果的最佳方法.

创建一个存储同一类型实体列表的实体是一种智能方法,还是我认为这一切都错了？以这种方式做某事会在查询数据库时损害性能吗？

理想情况下,我想使用延迟加载并首先只显示顶层反向链接,然后在点击特定反向链接时,让EF再次调用以获取子反向链接等等 - 这样的存储方法也是如此延迟加载是聪明的,还是我应该废弃这个想法,并为此找出一个完全不同的架构？

我对EF并不擅长,所以任何有关最佳方法的见解都会受到高度赞赏.

Answer 1

您试图实现的称为邻接表。看来只添加ICollection<Backlink>;Backlinks 集合就可以了（当然，需要正确的模型配置）。然而，邻接列表本身并不是性能的好朋友，尤其是它在 EF 中的典型实现（正如您所建议的那样）。有两种选择：

1. 正如您所建议的，按需逐级加载链接。在这种情况下，选定的模型本身实际上工作得很好（每个级别都是非常简单的 SELECT 就像 @Danexxtone 提到的）。但是，您会对应用程序服务器/数据库产生大量请求。因此，用户体验可能不太好。
2. 您可能希望加载整个树以便立即向用户显示节点。使用 EF 执行此操作意味着导航集合上的递归，这实际上是最糟糕的想法 - 对数据库的请求太多。
   看来EF也没有更多的选择了。但是，您可以使用纯 SQL（顺便说一下，通过 EF 数据上下文）...并且还有更多有趣的方法：
   1. CTE（就像@Jon 提到的）。它在邻接列表上工作，无需对数据库结构进行任何额外的更改。不错的选择，但不是最好的。
   2. 树路径列。让我们将层次结构的根编号为“1”，将 1 级链接编号为“2”、“3”、“4”，将 3 级链接编号为“5”。树中的每个节点、每个链接都可能具有唯一的字符串路径，例如“1/2/5/”。只需在数据库中再添加一列“Path”，您就可以使用简单的 LIKE 表达式（甚至 EF 中的 .StartsWith）提取子树
   3. 我假设您使用的是 MS SqlServer DB。那么你有更好的选择——hierarchyid数据类型。EF 不支持它，但它提供了所有开箱即用的“树路径”功能。
      我写道 CTE 不是最好的选择。这是因为性能 - 使用字符串树路径的查询效率更高（不要忘记索引）。hierarchyid 的性能比树路径好一点，但它的优点是 - 用于树操作的内置 API。
      一种更有趣的方法是嵌套集。但是，我不推荐它 - 插入新节点的开销太大，而且编写代码并不容易。

结论

如果您熟悉 SQL 本身并在 EF 中使用纯 SQL - 最好的选择可能是 hierarchyid。
如果您想仅使用 EF 进行编码 - 邻接列表是唯一的选择。只是不要使用导航集合的递归遍历来检索深层子树 - 这可能真的很糟糕。