0

I have imported database tables from MS SQL Server 2012 and migrated them to Visual Studio 2015 using code-first concept shown in this example. Its working but just now i just added a new table in SQL Server and i wanted to update the DBContext in my project with the new table.

I tried entering "add-migration new_table_name" in the Package Manager Console but it didn't work. I understand that i have to code a new model manually in the Models folder of my project, then only that migration will work. But i feel like i'm more comfortable creating a table in SQL Server. So, is there any way i can just create a table in SQL Server and then update the migration to my project?

Will it do if i create another ado.net but this time i choose DB first? After that i'll delete the code first DBContext, configuration.vb and the models. Will it affect my project later on?

Nurul
  • 147
  • 1
  • 3
  • 15

2 Answers2

3

If your main goal is to create the tables first in the database and then automatically update your project then you should use Database First.

That said, you have to consider the drawbacks of Database First: in my personal experience I stopped using that approach mainly because of two reasons:

  • Database First support will be discontinued, as far as I know. EF Core does not include the editor tool. Some links about this: a post from Julie Lerman, the EF Core roadmap, and an early announcement from Microsoft.
  • The model editor had several bugs and quirks that caused the code to get broken every now and then. These bugs are most likely just not going to be fixed (see previous point). Things like changing the type of an existing field, changing foreign keys, etc.
  • I had a lot of problems because of source code repository merges of the auto-generated entity files. Especially (but not only) when several people were working with the same entities so we were getting merge conflicts in the auto-generated code. Also, the auto-generated code sometimes was not being checked-out correctly, so it got out-of-sync with the edmx. I'm not sure it this happens also to other people, but it seems that sometimes Visual Studio, the editor, the background auto-code generation tool and the TFS source code manager just don't work well together.

So if you really can't live without creating first the tables in the database go on with Database First, but you have to consider what you are losing if you don't use Code First. This approach is widely recommended by a reason.

Usually the main reason for people using Database First nowadays is the impossibility to migrate legacy code to the Code First approach. As far as I know it is widely accepted that Code First is the right way to go otherwise. Here you have an interesting post about this (even if it is a bit old, written for EF 4.1, when Code First was introduced, it deals with the main pros and cons of each approach).

A workaround for you could be to keep using Code First but also use the available tools that automatically generate your Code First entities by doing reverse engineering from the database tables. With this you can still generate your tables directly in the database, but keep on using Code First with migrations and everything. Here you have a post from Julie Lerman about some of those tools. There may be more recent tools, but I haven't used them and I don't know about them.

Note: my personal experience with Database First was kind of bad and didn't last too long. Perhaps someone with more positive experience in this approach could give more useful insight about it. I've been using Code First for a time now and really prefer this approach. My answer may be a bit biased.

Community
  • 1
  • 1
Diana
  • 2,186
  • 1
  • 20
  • 31
  • Thanks for the useful explanation and suggestion! I think your experience is enough to tell me what i should choose. I think i'll stick with code-first :) – Nurul Feb 14 '17 at 01:03
  • Could you please help me out [here](http://stackoverflow.com/questions/42362172/add-migration-error-object-reference-not-set-to-an-instance-of-an-object)? – Nurul Feb 21 '17 at 08:30
0

AFAIK,

EF migrations is supposed to serve the Code-First approach whereas you want to use database first, which means migrations is something that's not intended for you.

You can achieve most DB schematic features and customize the tables and its columns attributes by EF via data annotation attributes and EF fluent API by overriding the OnModelCreating method in your DbContext subclass.

Shimmy Weitzhandler
  • 101,809
  • 122
  • 424
  • 632
  • Can i simply copy paste other table's modelBuilder.Entity(Of .....) then add and change it to my new table's name in the OnModelCreating method? – Nurul Feb 05 '17 at 06:33
  • Or should i change to Database First then? – Nurul Feb 05 '17 at 07:05
  • will it do if i create another ado.net but this time i choose DB first? After that i delete the code first DBContext and the models. Will it affect my project later on? – Nurul Feb 05 '17 at 08:51
  • You have to make up your mind. It's either you use code-first then migration works out the box, or you use database first, then you generate model according to DB. I'm sure you can find hacks but I'm not sure it's worth the effort implementing it. Why do you want to use code first? Anything specific feature not available? – Shimmy Weitzhandler Feb 05 '17 at 21:47
  • At first its because i thought its simple, and because most tutorial sites recommend using them. I chose code first in the first place because they said its suitable for big projects that has hundreds of entities and involves lots of changes to the DB. But when i tried it myself i find it a bit too much work. Plus, my teammates more prefer creating the entities directly in SQL Server. At first i rejected DB-first thinking that hundreds of entities might cause confusion in the entity design. Will changing to DB-first be suitable for my case and allow me to create entities from SQL Server? – Nurul Feb 06 '17 at 01:01
  • You can reflect your current DB to generate a code-first schema. But that wouldn't be code-first. You can probably hack the T4 templates to allow fine tuning of the generated context so that you can make it code-first capable. – Shimmy Weitzhandler Feb 13 '17 at 02:06