recreating and disposing dbcontext in entity framework 5

Question

I have to maintain an application that was working when running on one machine. It is using Entity Framework 5 and the model was created using the database first method.

The application has now been installed on a second machine and updates to the database made from machine A are not being reflected on the second machine (B).

In the main form of the application an entity context is being created as such:

recordEntities = new RecordEntities();

and then all the sub forms in the application are being passed this original "recordEntities"

In the form on the second machine that is reading the record the code looks like this

 Record = (from b in recordEntities.records
           where
           b.JobNo == JobNo &&
           b.SerialNo == SerialNo
           select b).FirstOrDefault();

by adding the following code before the query I can get the updated record.

recordEntities = new RecordEntities();
// do query

My questions are:

• Is there a way I can "refresh" the 'recordEntities' without recreating the context ie something like:

recordEntities.Refresh();
// go on to do the query

• If I have to continue to recreate the context everytime before the query should I dispose it first ie

recordEntities.Dispose();
recordEntities = new RecordEntities();
Record = (from b in recordEntities.records
           where
           b.JobNo == JobNo &&
           b.SerialNo == SerialNo
           select b).FirstOrDefault();

Answer 1

For one, Entity Framework contexts are not designed to have a long lifespan . Precisely the fact that they cache everything they fetch from the database causes them to get bloated in no time. Performance will suffer and memory consumption may become intolerable.

Secondly, statelessness is the norm nowadays. In web applications (including SPA's) each view is new and expected to be new (except for specific tasks that span multiple pages, like filling out a complex application form). I think this is the kind of behavior people start expecting in smart clients as well. It is refreshing (pun intended) to start looking at smart client applications as web applications.

What does this mean?

• Activating a previously opened form should be the same as newly opening it.
• Navigating away from a form should be dealt with the same way as closing it, so it should not be possible without a decision what to do with unsaved data.
• User interactions design to be transactional, but spanning multiple forms should be presented as a coherent back-and-forth succession of forms, say a wizard-like user experience.

How is this related to your question? It means that context lifespans should at most be bound to view lifespans (forms or wizards) and that re-activating a view may as well start new context with fresh data. Taking it further, each database interaction could have its own context.

What I'm trying to say here is that the required short context lifespan can very well be combined with user interaction in smart client applications.

It may require redesign like reducing the amount of data shown in one view by paging in stead of dumping thousands of records a user will never be able to comprehend all at once anyway. Or like managing view state differently (like: which grid record should be re-selected as current when fetching new data). That's hard (I know, one of the applications I work on is still far from this stage) but rewarding, because it makes for lighter clients and (maybe important) any future conversion to web will be easier.