Actually, as I type I realise a problem (maybe this is what you speak of).

"IsNew" can be accessed without a database context. So perhaps the model I am thinking of would not be "entity.IsNew" but "adapter.IsEntityNew(entity)". This is probably quite a fundamental change, so I can understand hesitation in that.

pfew I'm glad you finally understood it.

Still, I think it's more accurate representation of the "IsNew" quality.

You mean, it should have been named 'Fetched' or 'Exists' and have a value !IsNew ? Isn't that the same thing?

What you suggest above is also giving other problems: the adapter has to keep track of its entities it fetched. That's not what it does: it's not a context or a cache, it's a piece of logic yuo use to do things. So if I fetch an entity E with adapter instance A and I save it with adapter instance A2, on the same DB, it should work properly, so A2 shouldn't have to look up what A did with E.

You mean, it should have been named 'Fetched' or 'Exists' and have a value !IsNew ? Isn't that the same thing?

I don't mind what it's called, as long as it doesn't prevent me from doing two inserts with the same Entity on a different database

What you suggest above is also giving other problems: the adapter has to keep track of its entities it fetched.

I'd just implement this with a 'FetchedDBContext' on the Entity, then a '.DBContext' on the adapter. The implementation of 'IsEntityNew' could use that to easily determine if it came from this DB.

It would only get silly if you tried to track an entity in its multiple saves. I.E DBA.Save() DBB.Save(); does that result in the Entity being saved "twice" and somehow that info is recorded? Maybe, but probably that's too confusing and weird, so I'd just go with saving the "Last Saved" information, and that's where it is. Still, certainly arguable that that would be totally different behaviour to what you have