I have a desktop application that is using Entity Framework bound to SQL Server Compact for persistence. The application stores various 'traditional' records (accessed periodically, but not modified very often), but it also is used for persisting highly mutable state used to restore application state between sessions.
Most of the recommendations I've read for Entity Framework involve keeping the DbContext lifetime relatively short (perhaps even method scope?), so as to avoid excessive memory usage over time. For the highly mutable state, though, it seems like having a longer lifetime makes sense; the mutable state persists for the entire lifetime of the app however, which would mean keeping a context alive for the whole app lifetime.
I've considered keeping a separate DbContext instance for just the mutable state, then use method-scoped contexts for other operations, but this runs into problems due to the mutable state having (read-only) references to the less frequently modified records; this causes errors when I try to modify them from another DbContext. I'm looking for suggestions from developers with more experience using EF as to the proper way to structure this.
Here is my current thought:
- Use a single DbContext with app lifetime for all mutable state and any records they reference.
- Use separate DbContext instances only for independent records, like data change history records and archived objects.
This still leaves a huge chunk of the database resident in memory all the time, but I'm not sure what else would work here. Database size isn't too large (on order of only thousands of records), so this might be okay.
Suggestions?