views:

145

answers:

1

I’m looking for a way to have fine grained control over what is saved using Entity Framework, rather than the whole ObjectContext.SaveChanges(). My scenario is pretty straight forward, and I’m quite amazed not catered for in EF – pretty basic in NHibernate and all other data access paradigms I’ve seen. I’m generating a bunch of data (in a WPF UI) and allowing the user to fine tune what is proposed and choose what is actually committed to the database. For the proposed entities I’m:

  1. getting a bunch of reference entities (eg languages) via my objectcontext,
  2. creating the proposed entities and assigning these reference entities to them (as navigation properties), so by virtue of their relationship to the reference entities they’re implicitly added to the objectconext
  3. Trying to create & save individual entites based on the proposed entities.

I figure this should be really simple & trivial but everything I’ve tried I’ve hit a brick wall, either I set up another objectcontext & add just the entity I need (it then tries to add the whole graph and fails as it’s on another objectcontext). I’ve tried MergeOptions = NoTracking on my reference entities to try to get the Attach/AddObject not to navigate through these to create a graph, no avail. I've removed the navigation properties from the reference entities. I've tried AcceptAllChanges, that works but pretty useless in practice as I do still want to track & save other entities. In a simple test, I can create 2 of my proposed entities, AddObject the one I want to save and then Detach the one I dont then call SaveChanges, this works but again not great in practice. Following are a few links to some of the nifty ideas which in the end don’t help in the end but illustrate the complexity of EF for something so simple. I’m really looking for a SaveSingle/SaveAtomic method, and think it’s a pretty reasonable & basic ask for any DAL, letalone a cutting edge ORM.

A: 

I'll answer this myself - sofar I've found no solution for EF1. EF4 will allow you to implement this with self-tracking entities, ie. you'll need to roll your own classes with T4 templates so there's a bit of a learning curve there (see link at end).

For now, we've decided to give our domain objects interfaces (which irks me as I really like working with poco classes in nhibernate/wcf which kills the need for this) and implement 'proposed' entites which we work with til the user decides to commit to the database, at which point we map to an EntityObject.

Some actual answers here:
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/32b04a36-0579-4d6f-af48-9cb670a3d9ff

nite