@dkf said:
It's fine if the DB is subservient to the application (e.g., it's just acting as a persistent data store) and saves a bunch of typing. If it's the other way round, which happens any time the DB is shared between apps, then You Don't Want Code First.
How does code first save a bunch of typing?
I'd argue that a code-first model actually is easier to maintain as the database grows (i.e. is of non-trivial size). The usability of the visual edmx editor leaves a lot to be desired (not to mention editing the raw edmx file itself ), whereas you have complete control if you write your own classes and specify your own mapping.
Though it's often a headache to create a good code-first model from an existing database (again, of non-trivial size), even with the available tooling, we've been ditching the edmx file and converted to code first in a couple of bigger projects since it (at least for us) will pay off in the long run. (And since only code first is supported in EF7...)
IMO, YMMV etc. And both approaches suck in their own respective ways.