A few days ago, I had the opportunity to speak with a Tech Architect (we’ll call him Bob) who worked for a consulting firm.  Being that we both utilized .NET for back end development, Entity Framework Core came up in our discussion.  Bob discussed how he made use of EF Core’s Database First Approach, which seemed odd to me.  Sure, Entity Framework did have a Database First Approach at one time (I wrote about it a few years back), but it was my understanding that the feature never had been released in Core.  What gives?

Before we dig any deeper, let’s take a moment to review each Approach that MS made available to us with EF 6.  Below are copypastas from the first blog post in my “Exploring Entity Framework” series that I wrote a few years back… 

Database First Approach: The database first approach allows developers to select the tables they wish to interact with in their application.  Once this selection is made, Entity Framework will automatically generate models for each table, and generate an EDMX file that shows each table and all relationships between entities.  The advantage with this approach is that it allows developers to quickly setup their models. This approach works very well if you have an existing database and do not plan to modify its architecture via the application.  Should any changes be made to the database by a DBA, the developer would simply need to refresh the EDMX file so that it pulls those changes into the application’s models. If you wish to make modifications to the model that will not be overwritten after each refresh, you will need to supplement them with their own partial class.  

Code First Approach: The code first approach gives developers the most control over their models by allowing them to freely modify their attributes.   With code first, you can create a new database for your app using database initializers and migrations. You can even work with an existing database by reverse engineering your models,  which is done selecting the tables you want and having Entity Framework generate the code for you. Unlike the Database First Approach, Code First does not come with an EDMX file.  Additionally, if your database properties are controlled on the database end, you will need to modify your models manually if their corresponding table architecture is changed in the database.  However, if you manage your database through the application, you can use code migrations to ensure that the models in your application are consistent with the entities they represent in your database.    

Model First Approach: The model first approach allows developers to visually design their entities using with an empty EDMX file.  This approach is similar to code first in the way that it takes the models created in the program and creates them in the database as well.  Additionally, the GUI available in the database first approach is used to help design the entities, so the developer can have a graphical representation of each entity and its relationship with others.    

The Problem
Here was the source of my confusion; The EF Core documentation does not mention any of the approaches above, but the Getting Started docs do show you how to create a database using a workflow that is identical to the Code First Approach from EF 6.  In fact, I had assumed it was Code First” without realizing it :
https://docs.microsoft.com/en-us/ef/core/get-started/overview/first-app?tabs=netcore-cli

The docs also show you how to reverse engineer models from an existing database, which was close to (but not the same as) the workflow with the EF 6 Database First Approach.  These instructions matched what Bob had described to me during our discussion:

https://docs.microsoft.com/en-us/ef/core/managing-schemas/scaffolding?tabs=dotnet-core-cli

It made perfect sense to me to call the first workflow “Code First” because I could not see how it was different from the approach of the same name in EF 6.   The one Bob called Database First still did not seem right to me due to the absence of the EDMX file.  Instead, it made use of the Scaffold-DbContext command to generate models from whatever tables were already in the DB.  Functionally, they are the same.  Additionally, Bob was not the only one to feel this was a Database First Approach for Core; a quick Google search of “ef core database first” shows other sites/blogs claiming the same thing:

This left me wondering, if the EF Core team wanted this to be called “Database First” wouldn’t they just say that in the docs?  Maybe asking other .NET developers might shed more light on the matter.

Onto Reddit

I had been semi-active on the /r/dotnet subreddit, and thought it would be the perfect place to get clarification.  My post was met with immediate feedback, most of which agreed with Bob’s stance.  The overall take was that a Database First Approach was more a workflow and less a feature, so the absence of the EDMX diagram was moot.  But one post stood out from the rest:

Huh, so who is /u/bloodytemplar and why is his stance different from the others’.  As it turns out, he is a Senior Content Developer for MS named Cam Soper.  Although he is not a member of the EF Core team, Cam had been tasked with putting together a series of Youtube videos aimed at teaching developers how to make use of the ORM.  He stated that the EF team no longer wishes to use the Code/Database First nomenclature and they had asked him not to reference them in his tutorials.   Given that I use this tool every day at work, I wanted to understand why this was not called out in the docs and what we should call these approaches now.

Ok, so what was Code First is now “Model/Code as the Source of Truth” while the approach formerly known as Database First became “Database as the Source of Truth”. The justification for these name changes is that you can switch between using each approach for the same app, which makes sense to me as this did not seem like something you could do easily with EF 6.  At the time of this writing Cam is touching base with the EF Core team to see why this has not been called out in the documentation, so hopefully we will hear more about these new naming conventions soon. 

Moving Forward

Knowing that the Database/Code First nomenclature was intentionally left out of the docs, it’s important to understand that more developers will be less familiar with them as time goes on.  Being that I started using C# professionally in 2018, I only knew of each approach because I had tried to get EF to talk to an Oracle database at my first .NET job (Spoiler Alert: Oracle DBs were not compatible with Core at the time so I had to use EF 6.  It did not go well, and I switched to Dapper).  If you find yourself conducting interviews and want to test a candidate’s knowledge on EF Core, focus less on their knowledge of each approach and more on how they work with the ORM. 

Inversely, educators should take the time to go over each approach.  If and when the EF Core team communicates these changes to the general public, it’s not guaranteed hiring managers will become aware right away.  This opens the opportunity for students to be asked about each approach when looking for their first job, and we should make sure they are equipped to handle these questions.