.net - What is a good model structure for a WPF and EF application? -

short question: there best practice setting single model handle both lazy loading features of ef , interface sync of background data changes wpf?

longer explanation/question (and current solution):

there plenty of articles explaining mvvm wpf, , plenty of articles working basic model classes , dbcontext’s ef, none (that i’ve found) tie 2 together,

my application client-side wpf application uses ef persist data generated application local sqlite database; there background worker threads wpf application fire off returns data other locations require persisting, data saved database if threads complete , returns wpf application while running - otherwise results discarded , app try running thread again next time,

now run problem….

ef requires virtual icollections lazy loading (which require) in order ensure background data syncs displaying on wpf applications, need use observablecollections , implement inotifypropertychange interface other fields - example - have customer class has collection of purchases within it, in order accommodate both ef , wpf requirements, need purchases represented both virtual icollection , observablecollection,

my question around there best practice keep single, unified model supports both ef , wpf?

my current approach have 2 models - “working” viewmodel , “persisted” model.

the working model has same data persisted model, working model sits in viewmodel of wpf application - , has data collections observablecollections, notify code hooked it, , business logic (followed nice article here ). persistence model made of pocos , has collections virtual icollections lazy loading , has no other job other work ef. when application loaded up, within app.xaml.cs file, load need “persisted” model sqlite “working” viewmodel wpf , let application thing - load additional persisted data working viewmodel required.

i forward thoughts/other solutions.

thanks

---

i don’t blog, i’m sure there bare bones of blog post in this!

another solution has come me, might scrap ef altogether doesn't neatly fit design - maybe custom data persistence layer instead.

it’s worth noting application isn’t massive spanning 100s of model classes, there maybe going around 10 when completed, work situation - prevent myself having work if can - , learn new things - looked briefly @ fody weaving inotifypropertychange elements model, hit issues .net 4.6 backed out - have enough moving parts @ moment without trying deal understanding , debugging else’s code.