I couldn't help noticing that you were swinging a very big hammer when you merged the entire contents of the child manager into the main manager. It's also a good thing that you aren't deleting in the child manager because the entities deleted in the child manager would not have been removed from the main manager.

 

May I suggest an alternative?

 

The EntitySaveOperation (like the EntitySavedEventArgs passed to a Completed event handler) contains an Entities property which contains every entity actually saved*. You can IMPORT just these entities (see EntityManager.ImportEntities) into the main EntityManager.

 

Ah ... but I haven't talked about deletes. The import would be a disaster if you had deleted entities as part of the save ... because you would import deleted entities into the target manager.

 

It seems both the big hammer and the little hammer leave (or put) deleted entities into the main manager. What to do?

 

Answer: The deleted entities among the "Entities" collection will all have the "Detached" EntityState. Thus, you should: 

(a) import only the entities that are "Unchanged" (i.e., every entity in "Entities" except the deleted ones) and

(b) communicate the entity keys of the "Detached" entities (the deleted ones) to the caller so it can remove the corresponding entities from the main EntityManager's cache.

 

Almost needless to say, I hide these mechanics in helper classes.

 

Bonus: Manager-to-Manager importing and exporting works great when the two managers (wrapped, I hope, in repository classes) should conversed directly with each other.

 

In many applications, the repository that saves has no idea who is interested in the saved results. This is a perfect case for some kind of message using the EventAggregator pattern. The saving Repository sends an "EntitiesSaved" message whose payload includes the contents of the "Entities" properties. Message receivers (which should be Repositories in my opinion) decide if any of those entities are interesting and do whatever they should do.

 

All of this looks to be fodder for a future cookbook example.

 

--

 

* It is possible to tell the server NOT to send back certain entities. The ones you filter OUT in this manner would not appear in the Entities property ... for obvious reasons. I assume you have not availed yourself of this highly specialized feature. Let me know if you have done so  ... or want to do so ... and I'll explain both how to do that and also how to remember to tell interested listeners about the entities that weren't returned to the client.

 

I assume that you are not using concurrency checking. Otherwise you'd be reporting concurrency errors when users started to work on an "old" copy of an entity that had not been returned from the server and merged back into cache.

 

It takes a user doing just the wrong thing very quickly to get caught in this race condition. You can narrow that window further by creating your own RestoreStrategy with a MergeStrategy of "OverwriteChanges" (you specify that MergeStrategy in the ImportEntities call if you go that route).

 

Of course the user might see the following sequence

• Modify Nancy Davolio to "Suzie" Davolio and save
• Immediately select Nancy Davolio again (her name hasn't been updated yet) and change her name to "Betty"
• Try to save "Betty"
• Concurrency error raised because "Suzie" is now in the database.

I'm sure you can imagine permutations.

 

The way to think about this is that each EntityManager is a different user. You either go the out-of-the-box concurrency strategy of last-one-wins or you turn on optimistic concurrency and start handling the inevitable errors.

 

 

Let's face it: 9 out of 10 applications go with last-one-wins ... in which case you can only strive to reduce the likelihood of a surprise: with Nancy become Suzie or Betty ;->  ?