0

我正在构建一个应用程序来显示源代码控制存储库中更改的历史日志。该应用程序在 .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

4

1 回答 1

1

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

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

于 2012-10-29T11:23:29.750 回答