Entity Framework – Benefits of Code-First vs Designing Database with SQL

centity-framework

I'm currently working on designing a small web application (MVC5) and I'm to the point of designing my database. I have the schema I want worked out and I am quite proficient in SQL Server. (I have my SQL 2012 MCSA.) I'm going to be using entity framework 6 as my ORM. I've been quite interested in the code-first approach because I'm not a big fan of designers and I like to be able to see and work with the code myself.

Because my SQL skills are quite strong I am inclined to create the schema myself and write my own CREATE TABLE queries, etc. I feel like that gives me a lot more control over constraint and index creation.

But I haven't really worked much with entity framework in the past so there may be some benefits to this that I'm missing. I know you can do code-first against an existing database in EF6 anyway, so that would be another option.

I've tried googling around a bit and reading MSDN but most of the benefits seems to be that you don't need to worry about the SQL. Since that isn't a concern of mine I'm failing to see the benefit of allowing entity framework to create my schema.

Are there any benefits to allowing entity framework to create my database that I'm missing?

Best Answer

The biggest benefit in my opinion is that it allows you to focus on designing the model, not the database used to store it.

This makes things like separation of concerns etc. easier as your mental approach is already doing that by seeing entities as simple classes, not database tables.

Of course, you can always use Fluent API and data annotations to tweak the generated database scheme where needed, and once things settle down you can switch on migrations and use that to generate the comfort blanket that is SQL scripts (in a good way!) for deployment and schema management going forward.