WPF 应用程序中的 EF Code First 对象图内存使用

Question

我正在构建一个应用程序来显示来自源代码控制存储库的更改历史日志。该应用在 .NET 4 WPF 和 Entity Framework Code First 中实现。

我遇到的一个问题是，随着时间的推移，随着更多日志条目被添加到日志中，应用程序会使用越来越多的内存并且不会释放对日志条目的引用。每个日志条目都包含一个“已更改文件”列表，并且对于每个已更改文件，文件的前后版本。

UI 显示日志条目列表以及当前选定的LogEntry 和ChangedFile 的新旧版本之间的差异。数据模型大致如下：

public class LogSubscription
{
    public List<LogEntry> Log { get; set; }
}

public class LogEntry
{
    public List<ChangedFile> ChangedFiles { get; set; }
}

public class ChangedFile
{
    public string OldVersion { get; set; }
    public string NewVersion { get; set; }
}

由于我使用的是 EF Code First，因此只需访问 List 属性即可查询数据库并自动构建对象模型。我想做的是在一段时间后以某种方式取消引用ChangedFiles 列表，并根据需要重新查询数据库并重建对象模型（即用户已单击返回日志条目）。

EF Code First 有什么方法可以做到这一点？或者我应该采取不同的方法来控制所使用的内存？

应用程序和完整源代码托管在 GitHub 上：https://github.com/tomhunter-gh/SourceLog

Answer 1

正如评论中所说：这很可能发生在从未处理过的静态上下文中。我在源代码中看到有一个ThreadStaticContextBackground 被LogEntry 使用：在类似活动记录的模式中，LogEntry 通过其MarkAsReadAndSave 方法保存自己，为此它需要一个上下文。

您可能这样做（我并没有仔细检查源代码）以防止在保存日志条目时创建和处置许多上下文。但我认为你应该重新考虑主动记录方法。日志条目由MainWindowViewModel 保存。视图模型应该调用一个服务方法，该方法通过一个短暂的上下文保存日志条目，并可能缓存这些条目以使其可用于显示等。它应该从DgLogSelectionChanged接收RemovedItems集合以便处理它们通过一个上下文而不是每个项目一个上下文。这有意义吗？