CODEWITHSUNDEEP
c#wpfmemory-managemententity-framework-4.1ef-code-first
Tom Hunter
Tom Hunter

Reputation: 5918

EF Code First object graph memory use in WPF app

I'm building an app to display the historical log of changes from a source control repository. The app is implemented in .NET 4 WPF and Entity Framework Code First.

One of the problems I'm getting is that over time, as more log entries are added to the log, the application uses more and more memory and doesn't release references to the log entries. Each log entry holds a list of "changed files" and for each changed file, the before and after version of the file.

The UI displays a list of log entries and the diff between the old and new version of the currently selected LogEntry and ChangedFile. The data model is roughly as follows:

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; }
}

As I'm using EF Code First, the database is queried and the object model is built automatically by simply accessing the List properties. What I'd like to do is somehow de-reference the ChangedFiles list after a certain time and have the database re-queried and the object model rebuilt as necessary (i.e. the user has clicked back onto the log entry).

Is there any way to do this with EF Code First? Or should I be taking a different approach to control the memory used?

The app and full source code is hosted on GitHub here: https://github.com/tomhunter-gh/SourceLog

Upvotes: 0

Views: 203

Answers (1)

Gert Arnold
Gert Arnold

Reputation: 109255

As said in the comment: this is likely to happen with a static context that is never disposed. I see in the source that there is a ThreadStaticContextBackground which is used by a LogEntry: in an active-record like pattern a LogEntry saves itself by its MarkAsReadAndSave method, for which it needs a context.

You probably did this (I did not really scrutinize the source) to prevent creating and disposing many contexts while saving logs entries. But I think you should rethink the active record approach. Log entries are saved by the MainWindowViewModel. The view model should invoke a service method that saves log entries by a short-lived context and possibly caches the entries to have them available for display etc. And it should receive the RemovedItems collection from DgLogSelectionChanged in order to have them handled by one context instead of one context per item. Does that make any sense?

Upvotes: 1

Related Questions