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 g开发者_如何学Goo 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!
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.
精彩评论