Is there an alternative to Code First Migrations with EF when all code changes are done by a DBA?

Question

I\'ve read about Code First Migrations but it seems that this is not really suited to the Enterprise.

We have a DBA that does all our Database changes and we don\'t nee

Answer 1

A bit late in replying, but here goes:

If you use the EF Power Tools extension for Visual Studio, it gives you the ability to do what Rowan Miller calls "Code Second". Take a look at this article.

It lets you point to an existing database and it will generate nice POCO classes and use DbContext just like if you had done it via Code First. No more ObjectContext or edmx files. The fluent configuration is also fully generated for you.

Moving forward, the EF team will be rolling this feature into the main EF tooling so you don't have to download the EF Power Tools extension.

Answer 2

Usually in such cases people use Database First approach.

Writing entities code manually when someone already designed database for you and when you can generate or update the model with several clicks just makes no sense. Of course, Code First could be convenient if your team is familiar with some other ORM where it was main approach and is not quite familiar with Entity Framework yet, or if your team is extremely small and nobody can write SQL script, but if you have skilled DBA, why you could need Code First?

Answer 3

Few days ago i faced the same problem,

old database, the __MigrationHistory table is

made change in the database and recreated it at local machine

added ContextKey, Model and ProductVersion from the __MigrationHistory table of currently created database, to old database’s __MigrationHistory table.

oh don't forget to use alter scripts to old database. For more just check,

http://www.codeproject.com/Tips/800936/Entity-Framework-code-first-migrations-alternative

Answer 4

To me it doesn't seem like these other answers are sufficient.

You can turn off the EF initializer:

public ApplicationContext : DbContext
{
    public ApplicationContext()
        : base("ConnectionStringName")
    {
        Database.SetInitializer<ApplicationContext>(null);
    }

    // DbSets here
    public DbSet<Part> Parts {get; set;}

    // override OnModelCreating below ...
}

And then use Fluent API / data annotations however you normally would to setup your POCOs/models to match the existing DB.

Details at this blog: http://cpratt.co/entity-framework-code-first-with-existing-database/

In case that URL does not work in the future - here's what I mean:

After having set the Initializer off above, configure your POCO's that correspond to a table:

public class Part
{
    public string PartID {get; set;}
    public string Description {get; set;}
    public decimal Weightlbs {get; set;}
    public decimal Price {get; set;}
}

Then map your POCO to the existing DB table by overriding this method in your Application Context class:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    // Code First will assume a lot, but if you need to override things:

    modelBuilder.Entity<Part>().ToTable("db_PartTable");
    modelBuilder.Entity<Part>().Property(p => p.PartID) 
        .HasColumnName("Part_ID");
    modelBuilder.Entity<Part>().Property(p => p.Description)
        .HasMaxLength(100)
}

Another good blog for this, by Scott Guthrie: http://weblogs.asp.net/scottgu/using-ef-code-first-with-an-existing-database

Answer 5

Even though I use EF Code First style (as opposed to EDMX), I am still technically using a database first approach because I never let EF generate the database for me. Instead, I create the classes to model the database. This sounds like what you need to do in your case.

As for the DBA changing things.. whether you need to update your domain entity classes depends on what it is that the DBA is changing. For example, if he is increasing the length of a varchar(100) to varchar(200) or something like that, then that change shouldn't really break your code (but it's still recommended you update your code to match this anyway). If he's removing or renaming some columns though, then you would definitely need to update your domain entity classes because that would obviously cause an exception regarding the underlying model not being in sync.

Answer 6

Just to add a few thoughts on this - take a look at these two posts (I made a while ago): https://stackoverflow.com/a/10164815/417747
https://stackoverflow.com/a/10255051/417747

In short, from my experience:

• you can't easily 'maintain' such a solution in a real enterprise size Db. Sooner or later the 'two worlds' are going to collide, synchronizing things might be painful (though doable)
• however you shouldn't give up on it because of that. It's good for jump-starting and with careful planning, syncing you can make this work for a while,
• you can dump the scripts and / or tweak the migration code, adjust the 'seeding' - to do away with some changes (still some limitations are painful and I doubt it'd ever going to 'mimic' what DBA can do),
• you can skip the 'generation' from CF once it goes too far (pretty soon actually, as soon as DBA takes over) - and just (using scripts and partly explained in posts) make sure your Db-s match (real and 'code' blueprint one). That still means you have most of the tables etc. setup and you'd need to tweak some things,
• this is a 'rule of thumb', in good chunk of cases CF won't be plausible - so just use it for prototyping then,
• for scenarios you're describing a good 'db generator' is probably a better solution (but it has some downsides as well), but I still haven't seen a good 'combo' of both worlds

hope this helps a bit.