Instead of having EF connect to SqlServer or Oracle or whatever ... have the ability to provide an InMemory provider ... so our unit tests or general development can be quick. There's no .dbf or whatever. No triggers or stored procs or views. Just list or hashset backing collections (behind the scenes). Simple, yet fast.

Example scenario's.

The common : Blog posts and Users. When a person creates a new blog post (which is represented as an entity on the edmx) and adds a User to that blog post, (ie. the user who is making the post), the inmemory context adds the instance to the BlogPost repository and to the user repository (if the user doesn't exist). All very simple crud BUT the EF is smart enough to 'remember' these enties, their data AND most importantly, their relationships.

Currently, if we create a generic IRepository<T> and some fake InMemory unit of works and/or InMemoryContexts .. they do know how to update other repositories -- relationship management doesn't exist.

So .. it would be so helpful if EF can handle an inmemory situation. We would have the manually populate the data for each repository/entity .. which is perfect .. so it keeps things simple .. but fast.