Although Microsoft has dropped support for EDMX as it moves to the next generation of Entity Framework, 3rd party providers have promised to continue supporting designer based tooling for EF Core. Since the EF team announced that it wouldn’t support EDMX going forward, I have asked the providers directly and shared their response that yes, they were planning to support EF Core. And I’ve been trying to calm the many developers who currently depend on EDMX and/or the designer and really want to use EF Core rather than sticking with EF6 and the existing tooling.

The two providers that have long had their own designer support for Entity Framework are LLBLGen and DevArt.

DevArt just announced the release of Entity Developer 6.0 which does indeed support EF Core. Within minutes of reading their tweet announcing this, I took it for a spin. Even though I’m mostly using Code First exclusively these days, I know a LOT of developers who have huge investments in EDMX and would love to use EF Core. So definitely wanted to see how this works.

I grabbed the Entity Developer 6.0 Professional Trial (the trial is free, a real license is not). Although Entity Developer has been around for years and I do have clients that use it for working with Oracle, this is the first time I’ve ever tried it out myself.

You do not need a designer to reverse engineer from the database! EF Core can reverse engineer from an existing database into POCOs and a DbContext. (Check out the scaffold feature in my MSDN Magazine article on EF Core Migrations.) The value of this designer with respect to EF Core is a) if you have an existing EDMX and want to continue using it or b) you want to do designer based modeling for EF Core.

Highlights:

• The most important part of the process is that this designer generates the DbContext class using the mapping and connection details needed by Code First and does so using EF Core APIs and namespaces.
• You can import an existing EDMX into their designer.
• You can create a new model via Database First or Model First in their designer.
• There is a special template for EF Core to generate DbContext and POCO classes from the model.
• You then use those classes in your application where EF Core as though you were using Code First.
• You can continue using the designer paradigm just as you’ve been able to do with EDMX. That means you can modify the database and update the model based on those changes, then regenerate your classes. You can tweak the model visually in the designer and regenerate the classes. You would not use Code First Migrations in this case.
• If you want, you could drop the designer after the first code generation and continue with code first and migrations. In that case, unless you really want to use the designer for this first iteration, you could use a straight database to code first workflow which is provided by EF Core migrations “scaffold” command or keep an eye on ReversePoco.com for it’s EFCore support.

Screenshots of creating a new model from an existing (very simple) database.

Create a new model, selecting EF Core as the model type.

Tell it that I want to use an existing database.

Choose a database provider (I picked SqlServer)

Select objects. I didn’t have a lot in my tiny demo database. You can see I chose a database that I had created earlier via code first…that’s why there’s a MigrationHistory table there.

Set up naming rules  Entity Developer has always had this. I just left it at defaults.

Define Model Properties. Notice some EF Core specifics on this page. Many to Many and Table Per Type support are disabled because they are not [currently] supported in EF Core. Also shadow properties is a new feature in EF Core and there is an option related to that.

Select a template  EF Core is there by default but you can create and save custom templates.

After this, the model gets generated and displayed in the designer where you can have your way with it.

Generate the code. This is an menu option under “Model” (or just press F7). This is the part I was sorely interested in of course.

When generation is complete, you get a message. It has created a DbContext class and one POCO class for each of my entities.

Then I created a new solution in Visual Studio a Domain Classes project and a Data Model project and copied the new classes into the relevant projects. Until I installed EF Core, there were loads of build errors.

Install EF Core into the DataModel project. It’s been a while since I used Powershell to do this so I forgot to add “ –pre” to the command. I’m sharing that because I’m sure others will make the same mistake! So don’t feel bad. I do it too!

The POCO classes are not very interesting. They’re just POCOs. The context class however, is where you can see that it’s using EFCore. I’ll share the key parts of that class.

EF Core namespaces:

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata;

EF Core OnConfiguring along with the EF Core DbContextOptionsBuilder and the UseSqlServer extension method.

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlServer(@"Data Source=(localdb)\mssqllocaldb;Initial Catalog=NinjaDomain.DataModel.NinjaContext;Integrated Security=True;Persist Security Info=True;User ID=;Password=");
            CustomizeConfiguration(ref optionsBuilder);
            base.OnConfiguring(optionsBuilder);
        }

Comprehends the new relationship mapping methods in EF Core:

  #region Ninja Navigation properties

  modelBuilder.Entity<Ninja>().HasMany(x => x.NinjaEquipments).WithOne(op => op.Ninja).OnDelete(DeleteBehavior.Cascade).IsRequired(true).HasForeignKey(@"NinjaId");
  modelBuilder.Entity<Ninja>().HasOne(x => x.Clan).WithMany(op => op.Ninjas).OnDelete(DeleteBehavior.Cascade).IsRequired(true).HasForeignKey(@"ClanId");

Enough for me for now

That’s all I did for the time being. I wanted to see the basic workflow. The big difference between EF6 (and earlier) and EF Core with respect to this is that at runtime,  EF6 (etc) would read the XML files that represented the EDMX and figure out the model from that. Even though the EF Designer generates code, that code is only for the sake of your own business logic. At runtime, if EF sees you are using an EDMX to describe your model, it relied on the XML files to learn about mappings to comprehend the model. EF Core *only* knows how to read the DbContext & classes, so it was key for the code generation to build those classes with all of the mapping details (and expressed via the EF Core APIs) that Code First needs to comprehend the model at runtime. That’s what the Entity Developer designer is doing for you. And as you can see from the screenshots, there was more to creating this support than simply modifying the T4 templates.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!