10

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?

Improve this question
2
  • 2
    If you change your classes to reflect the changes in the database you don't need migrations. Commented Mar 15, 2013 at 0: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? Commented Mar 15, 2013 at 0:45

6 Answers 6

Reset to default
6

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

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

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.

Improve this answer

3 Comments

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?
@Marilou, Adding a new table would not cause an issue. The problem is with changing existing mappings.
@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?
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.

Improve this answer

1 Comment

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...
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?

Improve this answer

11 Comments

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?
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.
what is the DbContext approach ? Is that part of "Code First"?
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.
This approach has no supported future.
|
0

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.

Improve this answer

Comments

0

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

Improve this answer

Comments