c# - Implementing Entity Framework for Simple Data Entry App -

this has been asked , answered 1000 times, google has not been not friend morning.

i'm making switch using stored procedures , business objects using entity framework. simplicity of generating pocos generated edm (database-first approach here). , how less typing is.

i'm having hard time wrapping head around suitable design common application scenario (in world, anyway).

basically, picture data entry application, let's online store's administrator (i'm doing in wpf, web-based).

the admin want view list of customers (manage customers view) in data grid. each row, there button edit customer or delete it. @ bottom of grid there button create new customer.

if delete customer, removed (after confirmation) data grid, back-end data store. if edit customer, window pops (edit customer view), displaying current data customer. can edit data, click either submit, or cancel. submit saves changes data store, , cancel discards changes. both buttons close window.

if, click new customer button manage customer view, new customer object created (not saved db yet), , same edit customer view opened, displaying new, blank customer.

here i've got far:

when manage customers view model constructed, populates public list of customers, like:

public list<customer> customers {get; set; }   using (webstoreendities context = new webstoreentities()) {     customers = context.customers.tolist(); } 

then, if admin user clicks edit button in customer row, bound customer object passed constructor of edit customer view. view constructs view model, has customer property view bound to. user can make changes customer object in view, either click save or cancel.

this lost. in business object/stored procedure implementation, have 2 customer objects: 1 customer being edited (bound view), , 1 copy of customer, called backupcustomer, used reverting changes if cancel out of edit customer view (since i'm using mvvm, properties of customer changed ui, , if start making changes, , click cancel, they'll expect not see changes in customer).

more point, if click submit in edit customer view, calls customer business object's save() method, reaches dal , fires off stored procedure update data store.

okay, on entity framework reality.

issue #1. there no way save individual entity. if extend customer entity have save() method, have create new webstoreentities context , call savechanges() on it:

using (webstoreentities context = new webstoreentities()) {     context.savechanges(); } 

that seems weird me. wouldn't think you'd want have entity instance creating entity contexts , stuff.

issue #2. in business objects implementation, cache objects, need ever fetch them db once. if make changes customer, great. call save() on , updates data store. same deletes , inserts. never have fetch same collection of customers more once (concurrency not issue on particular project). in ef implementation, every time open manage customers view, it's firing off code above list of customers. suppose keep 1 data context open during entire application, seems bad design too. tying connection the data store entire user session, because might open same view more once.

please me above issues, if can, don't hung on i'm (it's initial impression anyway):

it seems ef muddies logical boundaries in separation of concerns:

• you have keep copy of entity connection string in ui project (i keep business objects , data objects in separate project usually).
• you can't tell entity save or delete itself. have underlying context, typically in ui layer. in ui, able mybusinessobject.save() or mybusinessobject.delete(), knowing object knows how save or delete itself.

anyway, seems ef future, i'm going stick it. love recommendations.

thanks much!

the funk monkey.

while examples have implement queries surrounded using shouldn't in case. each ef context tracks it's own entity changes, using multiple usings won't know context did call savechanges on it. use 1 context per user , dispose when done (on exit, ect). can use singleton or static class, in desktop app doesn't seem make difference experience. in mvvm scenario may able away viewmodel handling context well, when instantiate viewmodel instantiate context , dispose context on dispose, might make more logical sense depending on how handle data internally.

for being able revert changes ef tracks both original db version of object changed version of object. information little convoluted:

disconnect , entity:

((iobjectcontextadapter)mycontext).objectcontext.detach(dbobject); var entry = mycontext.entry(dbobject); var original = entry.originalvalues; 

personally handle copying , keeping original object in code, it's cleaner , seems safer. it's faster, i've never run tests prove that. if you're in multi-user environment may benefit reloading data db though don't mistakenly display stale data.