0

I am developing an application that uses Entity Framework and WPF with MVVM design pattern. I have a number of entities, but to keep it simple, lets work with just a subset of them. Companies which can contain Contacts, Addresses, and PhoneNumbers; the aforementioned Contacts which contain Addresses, PhoneNumbers and Shipments.

Originally I was loading these entities from the database and leaving the DataContext open to use again later. This presented problems from a concurrency aspect as any of the objects that got updated may very well not be represented correctly in other parts of the program since those parts had not been updated.

I am trying something new. In my MainViewModel (which can easily be accessed from every other ViewModel) I have several ObservableCollections (my generic collection of choice when working with WPF Databound objects) which I intent to temporarily store my entities. Also there are several methods which will take care of adding entities to the context, attaching, detaching, saving changes etc. In my Record Collection displaying ViewModels (for instance the CompaniesViewModel) I have a backgroundworker load the entities, detach them, and store them in the Collections in MainViewModel. Unfortunately, I apparently have to create explicit queries such as:

Dim results = From Comp As Company In RVShipContext.Companies _
    .Include("Contacts.PhoneNumbers") _
    .Include("Addresses") _
    .Include("PhoneNumbers") Select Comp

Mind you, that is not so much of a problem, except when it comes time to load up a Contact and now I have to go back (attach, query, detach) to get the Addresses, and Shipments. Now, I don't have a real problem with that, but some of these graphs are going to be several layers deep. A Shimpent contains one or more Packages contains one or more DiskSets contains several disks.

Is there a way to load large graphs easily when using detached entities? Is there a way to use LazyLoading effectively when using detached entities? Is keeping my entities in a central set of collections (accessible to other parts of the program) a good idea or should I abandon it before I spend an inordinate amount of time setting up infrastructure for it?

Any help would be greatly appreciated!

CodeWarrior
  • 7,028
  • 7
  • 45
  • 76

1 Answers1

1

You should abandon your current approach. I don't understand WPF an VMMV but in case of MVP (model-view-presenter) you should use one ObjectContext / DbContext instance per Presenter and keep your entities attached. Check this article - it is about NHibernate but principle is the same. Similar approach should be used with VMMV.

The complexity of your query looks like you are trying to load everything to shared context which is very problematic solution. Especially detaching entities in stateful application like WPF app looks like big overhead and a lot of work to do when attaching changes back to context instead of using attached entities and let the context track changes for you. Also keeping entities attached solves the problem with lazy loading.

Community
  • 1
  • 1
Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
  • If I am keeping DataContexts one per view and alive, how can I manage concurrency between views? Some times I may have 10 edit shipment views open, each one reading the DiskSets and DiskSpecs. Originally I had an event attached to my main ViewModel which would be fired when an entity was updated and would alert other ViewModels, but I had some problems with that. – CodeWarrior Feb 27 '11 at 15:30
  • You can deal with concurrency only with data really saved to DB. So you still need 10 copies of data because it doesn't make sense to work with unsaved data in other views. So events look like way to go. When one view save changes event is fired and other views are informed and they can refresh their data. – Ladislav Mrnka Feb 27 '11 at 15:41
  • Well, that will do I guess. I have been getting mixed advice on Entity Framework for a while now. For one, it has built-in change tracking which can really only be used if you keep the context alive and don't detach entities. But then people say that the context should be used as Unit-Of-Work... *throws up hands* – CodeWarrior Mar 01 '11 at 13:49
  • @OffApps - but both these features can be used together but you can't share context among several "business transactions" which are represented as unit of work. – Ladislav Mrnka Mar 01 '11 at 13:51