My first coding foray into EF7 was as a code monkey for Pranav Rastogi from the ASP.NET team at TechEd Europe where he walked me through converting a simple EF6 app to EF7. (“Entity Framework Now and Later”, my bit starts at about 50 minutes in.) My next EF7 playtime was working through demos created by Rowan Miller (program manager on EF team) that are available here on his github account: https://github.com/rowanmiller/Demo-EF7/.
These demos depend on a snapshot in time of EF7 alpha (EntityFramework.7.0.0-beta2-11514) and demonstrate using EF7 & SQLite in a Windows Phone and Windows Store app as well as against a non-relational database (in this case Azure Table Storage). It also demos some other new features like batched updates, improved LINQ queries and more.
I used these same demos for a conference presentation which meant I practiced them repeatedly and modified them a bit to make sure it flowed in the way I preferred.
The bits are evolving rapidly. I’ve since been reading and writing about EF7 and played just a little but now I’m starting to have my most fun which is asking myself “what happens if I do X? what happens if I do Y?”, debugging, comparing and contrasting behaviors.
With the caveat that EF7 is still alpha and things are still evolving and shifting, I wanted to share some observations as I am playing with it.
1) InMemoryStore Before Committing to a Data Store
When you do any interaction with the DbContext even if you are not trying to query or save data, EF7 still wants you to specify the data provider in DbContext configuration. Since I’m not yet interested in actually hitting a database, the new InMemory provider is the perfect foil!
In DbContext, I can install the entityframework.InMemory package then specify in my DbContext class that this is the provider I want to use and then I’m good to go.
protected override void OnConfiguring(DbContextOptions options) { options.UseInMemoryStore(); base.OnConfiguring(options); }
I’d used InMemory for unit tests already but I was just using a simple console app to fiddle around EF7 with. That’s still testing, and that’s what the InMemory provider is for – testing.
What I’d like to do is be able to switch the context on-the-fly to use in memory store so I can have a single defined context with all of it’s dbsets, mappings etc and switch it easily to use my real data store or the InMemory store. So in a test project, I’d be able to say “use the context, but for these tests, use the InMemory store”. I see notes on github that this is a goal – e.g. specify provider along with connection string in a configuration file.
Rather than an enormous blog post, I’ll just publish this first bit and add more in bits and pieces …kinda how EF7 is being built anyway. 
\
) to ensure that EF migrations would change the database to have full text search enabled. Next was to change how EF queries are translated to SQL queries. This was a much trickier bit of code that benefited from the fact that with EF 6.1, the Mappng API was exposed so that we could code against it directly. The team was a little reluctant to expose that API only because it’s older EF code and quite a bit messier to work with than they would like. SO they do plan to clean it up but in the meantime, at least we have access to it. 
) on codeplex about making it easier to force the designer to use all fluent mappings if you want.
