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 need to have these changes put into Classes and have database migration performed by the application.

If we change our classes and our fluent API and then have our DBA make changes to the database then how can we sync to our EF model? How is this normally done for Enterprise size applications?

If you change your classes to reflect the changes in the database you don't need migrations. — NunoCarmo, Mar 15 '13 at 00:29
@NunoCarmo - Thanks for your feedback. So are you saying that if the changes are 100% correct then it will not complain about the model changing? What if there is some small difference, is there any way to see an error message or will EF just report that the model is no longer in sync? — , Mar 15 '13 at 00:45

Don Cheadle · Answer 1 · 2016-03-25T20:41:02.783

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

score 5 · Answer 2 · answered Mar 15 '13 at 01:37

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.

answered Mar 15 '13 at 01:37

Matt

6,787
11
65
112

Did you find any information or know how EF checks to see if the database and classes are in sync? What if I for example add a new table to the database but this is not related to my DbContext. Will it not cause a problem on initialization when it builds the model and finds things are out of sync? – Mar 15 '13 at 05:43
1

@Marilou, Adding a new table would not cause an issue. The problem is with changing existing mappings. – Matt Mar 15 '13 at 10:34
@Marilou why was this not the accepted answer? Your questions make it seem like this is the closest answer. If you're looking for something that automagically constantly monitors your hand-written POCOs with the Database... then you will not find it outside of using code-first migrations or edmx. Indeed - those are the things you would use, but it seems you want something else? – Don Cheadle Mar 18 '16 at 21:18

score 2 · Answer 3 · edited Apr 23 '13 at 02:19

2

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.

edited Apr 23 '13 at 02:19

Jesse

8,605
7
47
57

answered Apr 23 '13 at 02:00

Pofox

21
1

If you mean the outdated EF power tools (which was possibly just in beta version) and can be added even to VS 2015...still, this is just a tool and won't fix the main issues of this framework, which they call ORM... Using same exaggeration I could say "I have 2 ferrari-s in my garage". Btw. that was added to EF and VS itself is far beyond the original power of EF power tools... – baHI Mar 06 '17 at 20:22

Oleg Mikhailov · Accepted Answer · 2013-03-15T11:17:56.727

1

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?

edited Mar 15 '13 at 11:17

answered Mar 15 '13 at 10:44

Oleg Mikhailov

252
1
8

6

But doesn't the Database First approach create edmx files? Is there a Database First approach that just uses standard POCO and one which I can use the fluent API for? – Mar 15 '13 at 10:57
1

There never will be Fluent API for Database First. Both Fluent API and edmx file are intended to describe mapping between code and database, but in opposite to Fluent API this xml file can be generated by wizard in Visual Studio, you do not need write anything manually. As for POCOs, they are supported in Database First approach as well as DbContext. – Oleg Mikhailov Mar 15 '13 at 11:31
what is the `DbContext` approach ? Is that part of "Code First"? – Don Cheadle Dec 12 '15 at 23:07
Not at all. Earlier versions of EF had only ObjectContext, but when framework internals become more complicated EF team made attempt to add simplified wrapper around it and redesign their code, this wrapper was DbContext. That attempt failed and now they are trying to rewrite everything from scratch in EF7, in stable EF6 DbContext is default context type for new projects, but if you have old project migrated from EF4 you can still use ObjectContext. Because DbContext is just wrapper around ObjectContext both of them supports Code First, Model First, and Database First. – Oleg Mikhailov Dec 13 '15 at 11:18
4

This approach has no supported future. – Dave Feb 23 '16 at 23:05
I think it would be better ask ADO.Net team about their future plans, for the instance Rowan Miller in their blog at https://blogs.msdn.microsoft.com/dotnet/tag/entity-framework/ But I will be very surprised if he will say that this approach will not be supported in future. – Oleg Mikhailov Feb 24 '16 at 16:07
@Oleg - I think it's misleading to say that one cannot use `Fluent API` for `Database First`. If by `Database First` you truly mean the edmx database first pattern, then it is indeed true. But some people read it doesn't work with `Database First`, and rather than knowing the pattern known as `Database First`, will assume that if a database already exists, fluent API will not work. But as we know, this it not the case. – Don Cheadle Mar 18 '16 at 21:15
You are right. Now, in 2016 my comment that "There never will be Fluent API for Database First" is not true. – Oleg Mikhailov Mar 19 '16 at 09:24
Do not use Database First in multiple-developer environments. It's a merging nightmare. – Josh Noe Oct 28 '16 at 18:39
Josh, it depends on your source control system. In TFS and other centralized systems you simply lock file and do not merge anything. But with distributed systems such as Git it could be problem. – Oleg Mikhailov Dec 04 '16 at 15:09
Neither DB first, nor code-first. Both are nightmare. Starting from the "i do mapping for the idiot developers" auto-mapping feature (which I think can't be turned off), to the "must have foreign keys mapped in some cases" and so on. But the winner is EF core, with version 2.0 missing lazy load (or better to say missing proxies) that would raise an exception if you hit an unloaded property, instead of just silently returning NULL or empty collection. We're back in 2007, or so... – baHI Mar 06 '17 at 20:19

score 0 · Answer 5 · edited May 23 '17 at 12:00

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.

score 0 · Answer 6 · answered Jul 31 '14 at 15:32

Few days ago i faced the same problem,

old database, the __MigrationHistory table is enter image description here

made change in the database and recreated it at local machine enter image description here

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

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

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

6 Answers6

Linked