Is it good to use databinding to Entity Framework's Entity in WPF?

I created a singleton entity framework context:

  1. To have only one connection and it won't open and close all the time.
  2. So I can pass the Entity around to any class, and can modify the Entity and make changes to the database.

All ViewModels getting the entity out from the same Context and databinding to the View saves me time from mapping new object, but now I imagine there is problem in not using the newest Context:

A ViewModel databinding to a Entity, then someone else updated the data. The ViewModel will still display the old data, because the Context is never being dispose to refresh.

I always create new Context and then dispose of it. If I want to pass the Entity around, then there will be conflicts between Context and Entity.

What is the suggested way of doing this ?

2 Answers 2


The suggested way is don't do it -- results are unpredictable to the point of being dangerous to your data. You should not give the view direct access to the database. Results are unpredictable.

First, the nature of both databinding and the modern fancy ORMs is pretty heavy reflection and other similar stunts. Oftentimes things just don't work or just don't get updated in the way that the ORM expects so there are very odd bugs to track down. Second, those DbContexts are pretty stateful and there can be lots of complications when newing them up and passing in objects. Third issue is the potential for the SELECT N+1 sort of performance issues -- if you cut off database access then your view can't reach back to the database to do a sub-select for every single customer you put in the list, for instance. Finally, for non-trivial applications, one rarely sees scenarios where the front-end views want to talk to an object shaped like the back-end entities.

  • mhm, I see what you mean. So is suggested to always do the tranditional way, new context => query => maps to new object => databinding?
    – King Chan
    Feb 17, 2012 at 21:27
  • Yes, really the only way to fly. You've got to break the chain with the ORM. Feb 17, 2012 at 21:41

.net actually does a good job of managing the connections behind the scenes for you by pooling connections.

This is a classic case of optomising too early. You are actually much better off writing an application that works and bench testing to find the bottle necks rather than making assumptions and overcompicating your design too early. You may find you need to use the singleton pattern but I doubt it.

  • Right now I am just trying to create the basic structure of the application, so every newly create Window (View/ViewModel/Model) will follows the same work process and structure. So I want to make it as better as possible so I don't need to make big changes all overa again.
    – King Chan
    Feb 17, 2012 at 21:31
  • It's generally better to make it as simple as possible. (KISS). Only optimize the parts that need it. Making changes is better than having an over complicated design Feb 17, 2012 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.