Given the disadvantages of Model-First, we can think that Database-First might be the way to go. This can be true if we either have a Database already or don’t mind building it beforehand. That being the case, the Database-First approach is similar to the Model-First one, except that it goes the other way around; instead of designing the EDMX manually and generating the SQL script to create the Database, we build the latter and then generate the former using the Entity Framework Designer tool.

We can summarize it by saying that going Database-First will mean "building the Database and letting Entity Framework create/update the rest accordingly":

Here are the pros of this alternative approach:

• If we have an already-existing Database in place, this will most likely be the way to go as it will spare us the need to recreate it
• Risk of data loss will be kept to a minimum, because any change or update will be always performed on the Database

And here are the cons:

• Manually updating the Database can be tricky if we’re dealing with clusters, multiple instances, or a number of development/testing/production environments, as we will have to manually keep them in sync instead of relying on code-driven updates/migrations or autogenerated SQL scripts
• We will have even less control over the autogenerated Model classes (and their source code) than when using Model-First approach; it will require an extensive knowledge over EF conventions and standards, otherwise we’ll often struggle to get what we want