Before we can jump into the fray we need to decide how we want to approach modeling of our entities. There are two options and both have their advantages and problems. Today we’re going to cover both approaches, after that you’ll know which, Code First or DB First choose in your project.
Code First
As name says, we’re modeling our database base on C# code. We need to create entity classes which will respond to tables in database. Using this approach we can focus on C# code instead of SQL. Still you should make sure that EF generated right SQL when you finish, but most of the time, you can focus on model.
Code First is the best when you create everything from scratch. It’s true that writing model isn’t funny work, but writing it by yourself gives you more control, and it’s not that hard task having tools like Visual Studio. After all you’ll either create C# model or SQL script.
Additionally you can use tools like Devarts to generate C# code from existing database and start using Code First from that point.
Database First
Database First is used when you have already created database and want to generate model in C# base on database. You can also use this approach if you like SQL more than C#. Database First will speed up development if you have database already designed.
There is one problem thou. EF can’t deal with complex databases. By complex I mean unusual. It’s rarely seen in new projects, but if your application has some history it probably contains plenty of “hacks”. It’s possible that you’ll need to change your models a little or use other tools to generate models. Still it’s possible to do everything in a finite time.
Big difference
The biggest difference between two is how you’re going to upgrade your database. It’s sure that you’ll have to upgrate your database sooner or later.
Using Code First you’ll changing your database from C# code. So first of all change model and then generate migration. I’ll write about migration next time, for now know that EF generates SQL from migrations. Additionally you shouldn’t change database manually.
Using Database First you’ll changing your database manually and then regenerate entities. So again, if you trust SQL more than C# you’ll want to upgrade your database using manually written SQL scripts. Additionally you shouldn’t change entities manually, because every time you regenerate model every change will be overridden.
My opinion
For long time I liked Database First, because I could’ve generate schema for database using GUI in MS SQL Server Management Studio. It was easier to design when I could’ve see whole database scheme. After that, generating entities from my database came down to running one command in Power Shell.
After I read some articles I was able to see that I treated my models like strangers. They were placed in project I’ve never look into. I couldn’t change my models, it felt like I was doing everything from behind. To change models I had to change database scheme first. That’s why I tried Code First once, and from that point it is my main approach. As .Net developer I’m closer to C# code than SQL.
Verdict
Looking at it with an open mind, both approaches are valid. Both will do a job and this is what matters at the end of the day. Sometimes your decision will be dictated by your organization. Big enterprise projects have own rules. It’s common that any change in DB schema is checked by DB Admin and applied manually.
Modern companies will use tools to automatize this process like EF Migration or DacPac. But still there is conviction that automation of upgrading database is dangerous. We will dig into this topic in future, when I’ll talk about upgrading database in production.