How do I move from EF code first to a more traditional development strategy?

I am currently developing a small application with EFCF (EF code first) and MVC3. It seems that EFCF is great for developing a prototype or v1 application. What happens to my deployed databases after a v1 release? How would I go about deploying a v1++? Specifically the DB.

With EFCF I have 2 modes available, re开发者_JS百科create if different or recreate always. There is no "diff" mode that retains my data and patches model changes. How would I go about this? I figure I could diff the v1 DB with the v1++ DB and go that route, or I could migrate away from EFCF and go to the more traditional route of modifying the DB then updating my POCOs to reflect the changes. The problem is I don't really understand the latter and have not been able to craft a suitable Google query.

---

Any automatic tool for data migration is still something that should never touch your production database. Code-first approach is for development. You should turn off database generation once you move your code to the production and you should create change script for database when you upgrading to a new version. You can use some help tools to create diff script for you - like VS Database tools (VS 2010 Premium or Ultimate) or Red Gate tools.

---

2 links:

1. Creating the models from the database
2. Another article with more details

This method generates all the classes from the database schema. Here you are free to change your database schema. The only thing that you will have to do is update your entity data model but that doesn't affect your data nor should it break your code unless you are removing fields.

---

It seems that EFCF is great for developing a prototype or v1 application.

Bingo. Right now, EF4.1 doesn't t have any real versioning capabilities, although they are working on "migrations" and "schema evolution". Check out "What's Not Supported" here.

Personally, I really like code mapping, and so my recommendation is that once your initial schema is in place, that you make future changes by (a) modifying your database, (b) modifying your POCO's, and then (c) modifying your code-first mappings. You would, of course, tell your Database object never to drop your database.

This is can be error prone for big schema changes, but it will have to do for now.

---

I think you need the migrations EFCF feature.

The simplest way of not losing your data while changing models is enabling auto migrations with data loss allowed:

internal sealed class Configuration : DbMigrationsConfiguration<YourFancyDBContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = true;
        AutomaticMigrationDataLossAllowed = true;
    }

...

Database.SetInitializer(new MigrateDatabaseToLatestVersion<YourFancyDBContext, Configuration>());

Actually, it requires a few steps first: http://msdn.microsoft.com/en-US/data/jj591621