Question

In my WPF MVVM app, I’d like changes to my Entity Framework entity classes automatically persisted back to the database. I’ve had a few ideas about implementing this functionality, but none of them seem optimal.

Here are my current (non-optimal) ideas:

1. Use a DispatcherTimerto save changes every interval:

   DispatcherTimer timer = new DispatcherTimer();
   timer.Interval = TimeSpan.FromSeconds(1);
   timer.Tick += (sender, args) => Repository.SaveChanges();
   timer.Start();
   

2. Save changes in the program’s OnExit() method.

   protected override void OnExit(ExitEventArgs e)
   {
       Repository.SaveChanges();
       base.OnExit(e);
   }
   

3. Save changes every time OnPropertyChanged() is called on one of my Entities:

   protected virtual void OnPropertyChanged(string propertyName)
   {
       Repository.SaveChanges();
   }   
   

4. A combination of 2 & 3; save the data after counting an arbitrary number of property changes and also save in OnExit() to catch any changes that didn’t reach the change limit:

   const int limit = 5;
   int changes = 0;    
   
   protected virtual void OnPropertyChanged(string propertyName)
   {
       if (++changes == limit)
       {
           Repository.SaveChanges();
           changes = 0;
       }
   }
   

I assume 1 & 3 are the worst performing out of all of them, and 2 (not 100% sure) won’t save any changes if the program crashes. 4 is my preferred option as it balances the amount of saves that are performed.

So, my question is: In your experience or otherwise, what’s the best way to approach/tackle this problem?

Thanks in advance.

Answer 1

To digress a little; do you also allow a manual way for the user to save? I believe this is important to the question, as it should help determine how stringent you need to be with your auto-save behaviour.

Another consideration; are partial commits allowed? If a user changes one piece of information, the auto-save kicks in, the user changes another piece, and then the app crashes. Is it possible that auto-save could allow data corruption due to the fact that it has saved what was supposed to be an atomic operation that hadn’t fully completed?

Now, since you mention that the database is a local one, you don’t have to worry too much about the latency of a client-server database. That means that a high frequency of commits should be fine. Therefore, I’d rule out option 2 completely. Saving once on exit seems too risky.

I like the idea of reacting to property changes and saving then, but only if the partial commit consideration above isn’t going to be a problem. It will ensure all data is committed on a timely basis.

If the user has a way of manually saving their data, I’d probably go with the timed approach. Set it to 10 seconds (or some value), and fire off the auto-save, with a notification displayed to the user that the auto-save has fired.

The main thing to worry about, I believe, is what the user expects to happen. If you’re committing on every change, the user will (probably) not be surprised at the state of their data on a crash. Same goes with the auto-save notification. Informing the user of the save intervals will allow them to shrug off a crash, having confidence that the state of their data will still be relatively fresh.