what is advantage of CodeFirst over Database First?

Question

I was watching some videos and tutorials for EF 4.1, and I do not understand any benefit of CodeFirst (except some if DB is very small 3-4 tables and I am lazy for creating DB first).

Mostly, the best approach so far is to create Database in some sort of Database editor, which is sure faster then editing in the Entity Model and EF picks up every relationships and creates associations correctly. I know there are challenges in naming convention etc, but I feel its very confusing to manage Code First as everything looks like code and its too much to code either.

What is it that CodeFirst can do and Db first cannot?

Mintun

Answer 1

CodeFirst cannot do anything that DB first cannot. At the end of the day they are both using the Entity Framework.

The main advantages of using codefirst are:

• Development Speed - You do not have to worry about creating a DB you just start coding. Good for developers coming from a programming background without much DBA experience. It also has automatic database updates so whenever you model changes the DB is also automatically updated.
• POCOs - The code is a lot cleaner you do not end up with loads of auto-generated code. You have full control of each of your classes.
• Simple - you do not have a edmx model to update or maintain

For more info see Code-first vs Model/Database-first and here Code-First or Database-First, how to choose?

Erastatus

Honestly writing c# code for properties and metadata is quote slower and difficult to manage when no of properties go beyond 10 which is very likely to happen. As far is code is generate I don't care how dirty it looks. Auto updating database, this sounds interesting, I will check on it. – Mintun

Poor mapping capabilities invalidate CodeFirst, as your database will always reflect your entities... – Mulvaney

Answer 2

Coming from a DataCentric approach, I will always find it strange the people like to create in a Code First Approach. When I design my database, I am already thinking about what each of the tables are as if they were classes anyway. How they link together and how the data will flow. I can image the whole system through the database.

I have always been taught that you work from the ground up, get your foundations right and everything else will follow. I create lots and lots of different systems for lots of different companies and the speed that I do it is based on the fact that once I have got a strong database model, I then run my custom code generator that creates the Views/Stored Procedures as well as my Controller/BusinessLayer/DataLayer for me, Put all of these together and all I have to do is create the front end.

If I had to create the whole system in code first to generate the database, as well as all of the other items then I would image it taking a lot longer. I am not saying that I am right in any terms, and I am sure that there are probably faster and more experienced ways of developing systems, but so far, I haven't found one.

Thanks for letting me speak and I hope my views have helped a little.

Gisellegish

I found code first absolutely useless, we either have database ready or we create database easily with database tools and we have text template that reads database and generates code first model. Database designers are easier to visualize and change. And above all, you have full control. – Mintun

if someone having hands on in .Net framework then he/she can be faster in code first. But anyways main difference is for small applications you can use code first for faster approach ( though you can be faster in db first also all it depends on your mindset and startup skills.) – Tinctorial

Answer 3

Migration was enabled in EntityFramework 4.3 for CodeFirst , so you can easily update changes from model to the database seamlessly Reference 1

detailed video:Complete Reference Video

Sergent

Answer 4

Well, it depends on your project. I'll try to make a synthase some ideas:

• You have total control on the entity classes. They are no more generated, you don’t have to update T4 templates or use partial classes…
• EDMX model will disappear in EF7 in favor of CodeFirst model. So keep in mind if you plan to migrate to EF or you have projects start in the near future that could use EF7.
• Easier to do merge in case multiple devs are working on the model +/- Annotations and mapping should be done manually. I would say code first approach seems lighter (less bloat) and we can keep things simple (visual model could hide undesired complexity). Open to Fluent API.
• You can still visualize model via Power Tools, but the model is read-only. Any change to the model should be done manually (even the initial entities can be generated from scratch). You don’t have partial models (diagrams), but our models should be small enough.
• It seems database first is better integrated with SPs and function results (some improvements have been done in EF6)

Scraper