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.

I’m getting a lot of folks asking me about the announcement that EF7 will focus on code first and there will be no support in EF7 for designer based EF models.

I’ll give my two cents, even though I do think the EF team has been pretty clear about this in both their blog post about EF7 plans 

EF7 – New Platforms, New Data Stores

and in Rowan Miller’s TechEd talk where he devoted the last 20 minutes to early look at early bits and early thoughts about EF7

Entity Framework: Building Applications with Entity Framework 6

Here’s the scoop: EF6 and the designer will continue to be available and worked on but the big effort will go into EF7 going forward. Personally, I can’t promise it will be around 10 years from now so please don’t bang down my door in 2024.

I’ve also been asked: “should I bother learning about the EDMX since it will not be in EF7?” I firmly believe that learning a bit about modeling via the designer helps get some of the concepts across for if/when you do code first modeling.

Also don’t forget about some of the 3rd party tools that provide designer support such as LLBLGenPro, Huagati Tools,  and DevArt’s Entity Developer. I’m guessing they will be moving their tools forward, though I haven’t looked into it yet.