Code-first appears to be the rising star. I had a quick look at Ruby on Rails, and their standard is code-first, with database migrations.
If you are building an MVC3 application, I believe Code first has the following advantages:
- Easy attribute decoration - You can decorate fields with validation, require, etc.. attributes, it's quite awkward with EF modelling
- No weird modelling errors - EF modelling often has weird errors, such as when you try to rename an association property, it needs to match the underlying meta-data - very inflexible.
- Not awkward to merge - When using code version control tools such as mercurial, merging .edmx files is a pain. You're a programmer used to C#, and there you are merging a .edmx. Not so with code-first.
- Contrast back to Code first and you have complete control without all the hidden complexities and unknowns to deal with.
- I recommend you use the Package Manager command line tool, don't even use the graphical tools to add a new controller to scaffold views.
- DB-Migrations - Then you can also Enable-Migrations. This is so powerful. You make changes to your model in code, and then the framework can keep track of schema changes, so you can seamlessly deploy upgrades, with schema versions automatically upgraded (and downgraded if required). (Not sure, but this probably does work with model-first too)
Update
The question also asks for a comparison of code-first to EDMX model/db-first. Code-first can be used for both of these approaches too:
- Model-First: Coding the POCOs first (the conceptual model) then generating the database (migrations); OR
- Database-First: Given an existing database, manually coding the POCOs to match. (The difference here being that the POCOs are not automatically generated give then existing database). You can get close to automatic however using Generate POCO classes and the mapping for an existing database using Entity Framework or Entity Framework 5 - How to generate POCO classes from existing database.
