How to sync model after using Code First from Database using Entity Framework 6.1 and MVC 5?

Question

Assumptions

• Using EF 6.1, MVC 5, VS 2013, C#

• I have an existing database model designed in Toad DM for SQL Server and it's very important keep it always updated

Steps and Notes

1. Using ADO.NET Entity Data Model I chose Code First from Database (new feature in EF 6.1) to generate the models. Note: Model classes and DbContext class generated successfuly but NO .edmx or .tt file was generated.

2. Next I added a new scaffold item: MVC 5 Controllers with views, using Entity Framework. Note: Success, controllers and views generated

Question

From now on I don't want to use Code First to update my database. Instead I want the models to be updated based on database changes. What to do next? If I don't have an edmx file will I not be able to update my model classes from the database?

Amalgamate

No EDMX was created because that is for database/model first development-- your choices are to adjust your mapping files and database in tandem, or to use Code First Migrations. – Matz

Ok, but if I don't have a edmx file I'll not be able to update my model classes from database? – Amalgamate

While you could in theory regenerate all of your classes using the 'code first from database' tool repeatedly, using Code First in the first place is a deliberate choice to use your code as the primary method for schema change. If doing migrations doesn't jive with your development style, I'd recommend switching methods to the one that fits best. (Database first) – Matz

sure, i got it. I've switched here to EF Designer from Database and the problem is solved. Thanks DanS. So, i believe the answer to my question is no, if I dont have a edmx file I'll not be able to update my model classes from database because a edmx file is not generated in Code First method. Right? – Amalgamate

That is my understanding, yes. Good luck! – Matz

If you want to update model based on database change you can try EF reverse engineering. For that install this tool visualstudiogallery.msdn.microsoft.com/… . – Protrusile

I found it useful to let Migrations build me a empty DB and Then do a Schema compare to the production DB and work out class changes – Comedienne

There's one more thing to add to Brian Vander Plaats' answer. In step 4 you'll also want to copy anything that is in the new StoreDBContextTemp.cs/ OnModelCreating method and add it to the existing StoreDBContext.cs/ OnModelCreating. Otherwise you would lose those configuration additions when you delete the new context class. – Steelhead

Answer 1

The Entity Data Model Wizard's Code First from Database does an excellent job creating your entity classes, as if they were created in the Code First style. What you are asking is if there is any way to keep these classes up-to-date as your database changes, similar to the EDMX style "Update Model From Database". From what I've researched this is not possible using the built-in tooling. However, here is one workaround that I've found useful:

Let's say I have database with a product table and customer table. Originally I created a StoreDBContext class, and selected product as one of my objects. Now I want to add the customer table as a new entity to the existing context. Here's how to do this using the Code First Wizard:

1. Create a new Entity Data Model, call it StoreDBContextTemp or whatever
2. Choose the code first from database wizard option
3. Select customer as an object to add (just customer) & complete the wizard
4. Open the newly created context file, StoreDBContextTemp.cs, and copy the virtual properties of your newly added entities:

public virtual DbSet<Customer> Customers {get; set;}

5. Paste these new properties into your Original StoreDBContext.cs dbcontext class.
6. Delete StoreDBContextTemp.cs, and remove the connection string for StoreDBContextTemp in app.config/web.confg etc.
7. You can now use Customer on the StoreDBContext class

If you add or remove tables you will need to manually adjust fields, but at least you won't need to hand write dozens of properties each time a new table is added to the model.

Isbella

That's a great workaround. I am also using it. However, I am wondering what Microsoft are thinking. There are many companies that cannot use migrations because of different teams working in different countries (db teams and developer teams). I really hope that they'll come up with an alternative of the Update Model From Database in the EDMX file, although it's unlikely. – Handily

Nice workaround! However, instead of adding manually new DbSet I completely remove context file before starting process the steps above so that I use original db context name as new model name and all dbsets are created for me automatically. I suggest to remove custom stuff from context file created by VS and put it into corresponding partial class of context db file. – Ephrayim

It seems like it would be a great idea to build a tool that could handle this for you. – Dutchman

Answer 2

One more option is just delete the auto generated classes from the project and once again generate them. While following this approach only thing we need to make sure that is we should give the same name for the data model(class name which inherits from DbContext ) as the previous one.Data model name is highlighted in below snap

Pledge

Answer 3

Three things.

1. There's no .edmx when you use Code First.

2. If you use Code First Migrations you would have to write first the code and after that migrate the changes to database. This helps you to have much more organized you code with no generated code which is an advantage.

3. There's a plugin in Visual Studio for doing contrary. Entity Framework PowerTools allows you to select the database and map it to objects.

https://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d

Mchugh

Answer 4

The best solution to me is deleting the model and recreate updated one with the same name, keeping in mind two points:

1. Personal extension methods implemented for the model;
2. Possible manual relationships between tables added to the model because of not setted up in the phisical db.

My personal solution:

1. Move all extension methods to another partial class that won't be overrided;
2. Insert all added properties of an entity to another partial class;
3. Keep track of all manual relationships in an help file, so you can add them again being sure not to loose anything;
4. Delete the old model and recreate one new with the same name and update it with the manual relationships of point 3.

Peppery