Tag Archives: EF6

What About EDMX When EF7 Arrives?

Data Access, ,

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.

Highlights of Rowan Miller’s EF6/EF7 Talk at TechEd 2014

Data Access

Yesterday afternoon, Channel 9 chose to broadcast the Entity Framework session presented by Rowan Miller, a Program Manager on the EF team at Microsoft. Rowan is an excellent presenter and the session was a 400 level, demo-heavy session. And it was awesome!

While the abstract promised an advanced demo-heavy session showing off features of EF6 (including the latest rev, EF6.1), Rowan also showed off some of the new functionality that will be coming in EF7.

Here are some of the highlights of his session.

The first part of the session dug into demos that showed off how you can combine features of EF6 to implement functionality that many developers would like to achieve in their applications.

The demos also used the recently released EF6.1 which has over 120 bug fixes plus a handful of new features. EF 6.1.1 is a patch release that is coming out soon. It is mostly bug fixes and some critical fixes to performance regressions that were introduced with EF 6.0.2.

The first of these was “soft deletes”, in other words for all intents & purposes, when you delete a record it is gone from the application. But it is not removed from the database. Rather than having to mark a record as “don’t show this to me again” and always include filtering in queries, Rowan showed how you can get Entity Framework to take care of these tasks in the background.  He combined the use of

  • Custom Conventions
  • Mapping Data Annotations to Custom Conventions
  • Command interceptors (for queries and change commands)
  • CommandTree Interceptor (in 6.1)

Here’s a slide where he laid out how he would pull off the whole thing:image

 

image

Next,Rowan demonstrated how you can enforce Entity Framework to automatically perform full text searches. This meant that first the database needed to have Full Text search implemented. Rowan used EF6’s Custom Migrations feature (a community contribution to EF6 Smile ) 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. Smile

The final EF6 demo showed how to leverage the support for using Mocking frameworks more easily in EF6. In addition, Rowan has created his own APIs (not an official part of EF) to help even more (mocking DbSets is hard!) so he used his EntityFramework.Testing API in his demo.

image

And then…..EF7 (sneak peek).

So the team has started working on EF7. It is a work in progress and open-source. You can find it at github.com/aspnet/entityframework .

EF will undergo a “sea change” with this version. It is time to shed some of the 8 year old code in the APIs that is making it harder and harder for the team to evolve Entity Framework. EF6 will continue to evolve but for how long and to what degree, it’s hard to say. (My words, not Rowan’s). EF7 will absolutely introduce breaking changes. BUt the most important patterns, e.g., basic DbContext interaction, will remain in tact.

Rowan demo’d two exciting features they are working on in EF7 so far.

The first is the ability to leverage your existing knowledge of EF to interact with NoSQL databases. An important note he made was that EF will not try to whitewash the type of data store that it’s connecting to. There will be functionality that pertains to relational that may not also pertain to NoSQL and vice versa. But basic CRUD operations, change tracking etc will be familiar if you’re already used to how EF works.

The other demo was working on a Windows Phone app where the app was able to persist data on the phone using Entity Framework (to a SQLite database).

This is of course, all *very* early stuff.

Rowan was clearly very exicted to share the EF7 demos, but the EF6 demos were equally impressive.

Plus he is a natural as a presenter. It was a pleasure to watch his presentation.

You can see it yourself here:

The Channel9 page for this session is here: Entity Framework: Building Applications with Entity Framework 6

First look at (beta of) EF 6.1 Designer

Data Access, , ,

EF6.1 is closing in on release. Along with the new DLLs that you can get via Nuget, there is a new designer that you can install into Visual Studio 2012 or 2013 via an MSI install.

Before installing, I uninstalled the EF Power Tools, because I wasn’t sure if they were included. Post install of the 6.1 Beta EF Designer, there was no indication of the power tool features in my context menu where it would normally be.

image

So it looks like this iteration of the designer won’t have the power tool features wrapped in except for the BIG one, the replacement of the reverse engineer into code first.  (So don’t uninstall those power tools! You can still use the other features like this one: my favorite).

With the new designer, when you create a new model, you now get 4 options. Two are familiar, EF Model from Database and Empty Model. The new ones are Empty Code First Model and Code First from database.

image

I chose Code First from database and pointed to AdventureWorks2012 and selected everything in the Human Resources schema.

image

This resulted in all of my new classes being created in my project, not in a folder.

image

Also, it added references to EF.

But the classes felt a little messy. So for my next model, I began with a new project folder. (note that I am only experimenting. I do not recommend having two models in the same project.)

image

Then I added the new entity model to th efolder, not the outer project. This time I selected the Person schema.

image

and all the new classes landed in my new folder

image

I prefer that. In a real app I would then separate the domain classes into their own projects and I would also put each of the models in its own project.

Let’s take a look at the domain classes that this generated.

Notice that tehre are data annotations. This is different than the EF Power Tools which put everything in fluent API code.

image

But those are annotations that are reasonable in a class since they are not solely defining a database mapping strategy.. required and stringlength can also be used by EF’s and .NET’s validation APIs. For the latter , think MVC validation.

But that’s not how this tool decides to use data annotations. Check the BusinessEntityAddress type.

image

It has annotations that drive the composite key creation and also that note database generated mappings. I wouldn’t normally put those in my domain types.

The rule that is being used by default is: any mappings that can be described with a data annotation are done that way. Everything else is done with a fluent api. None of my tables triggered any fluent api mappings. There is some discussion (started by guess who? Smile) on codeplex about making it easier to force the designer to use all fluent mappings if you want.

I was curious what Empty Code First Model gives us. It sets up a shell DbContext class. Makes sense to me.

image

I have been asking for the ability to select individual tables/views for reverse engineering an existing database into Code First context ad classes since the first public CTP of the EF Power Tools. (Here’s proof!) So even with a few things I’d like to see done differently, I am thrilled with this new designer feature.

Why?

For people building new apps with legacy databases, it is a great first step towards setting up DbContexts that  you can align with Domain Driven Design Bounded Contexts.  It gives me a nice stake in the ground to thinking within boundaries and also forcing me to think about when a customer in one context should be designed differently than a customer type in another context because they are used differently.

Any-hoo…there’s a quick first look for you. There’s still time to provide feedback to the team on the codeplex site. Go to this workitem: https://entityframework.codeplex.com/workitem/407

Also, as Erik reminds me in the comments, there is a  Visual Studio extension that provides some more extensive reverse engineer features into code first dbcontext and classes. You can find the docs, a video and the download here:  EntityFramework Reverse POCO Generator