I'm looking on Entity Framework at the moment and working with Code First example. So far I can see that the framework does not handle model changes easily: whenever I want to add another field to a class/table, framework drops the entire database and creates it from the scratch.
Similar behaviour I saw in (N)Hibernate. (I could be wrong here, it was long time ago)
That is ok, as long as I work on tutorial. When a real-life project is involved, you can't afford to drop a database every time you need a new field in a table.
Just imagine scenario, you are working on a project with many clients. Every client has their own database. In release 1.0.1 I need to add a new field to one of the tables. If I drop database in my dev environment - not a big deal. (Still, I need to run a script to populate test data every time DB is dropped, and sometimes even this is no viable)
But what do I do when I need to deploy this new version? Make a SQL script to update client's databases without dropping them? then deploy binaries?
But how is this better than doing database mods separate from code changes?
(sorry for my bad english)
This is exactly why Code First Migrations exists. Take a look here (automatic migrations) and here (code-based migrations)