Offer an in-memory provider to use as test double / fake database
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.
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.
An in-memory provider for testing is included in EF Core 1.0.
Henri Toivonen commented
im using tamas great project effort which he linked below
Martin Costello commented
I'm using SQL LocalDB to provide a midway between this and full SQL Server. SQL LocalDB comes with VS 2012+ so is available wherever your IDE is, and also potentially on your build servers if using TFS.
I've developed an OSS library for interop with the native SQL Local DB APIs which can be found here: http://sqllocaldb.codeplex.com/
Tamas Flamich commented
I am working on this: