1


I have been using SQL since 1985, so am very comfortable with DB servers.
I see (C#) Code First as yet another fad, that comes and goes. It seems to suit people that have no DBA background. Equally if using Code First and you have not idea what DB you are connecting to eg it might be Mongo later that too is a useful abstraction. Code First does not let itself to Database Diagrams so you can see what is going on.
I would like to know how you promote changes into a production SQL server using code first, where you have no desire to Drop and recreate the DB, unlike using an ALTER TABLE command. I have used tools from Red-Gate that make DB code promotions easy. So why Code First? How do you move DB Changes into production?

Doug Thompson - DouggyFresh
  • 430
  • 5
  • 15
  • 1
    You use migration scripts? EF covers this in their [tutorials](https://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application). [What have you tried](http://mattgemmell.com/what-have-you-tried/)? – lloyd Jun 08 '15 at 08:31
  • possible duplicate of [Using an ORM or plain SQL?](http://stackoverflow.com/questions/494816/using-an-orm-or-plain-sql) – rnofenko Jun 08 '15 at 16:20
  • Seems like it is migration scripts. Tho running 'update-database' is ok if there is no breaking changes. Discovering a whole mass of things you cant do in CodeFirst. Let alone setting things like GetDaate() or NewID() or Documentation for the DBA using EXEC sp_addextendedproperty N'MS_Description', Seems to be that you assume the DB is a dumping ground, versa an asset. But then its an abstraction I guess. – Doug Thompson - DouggyFresh Jun 26 '15 at 13:40

1 Answers1

0

The code first approach is something that is really nice to have when you're prototyping applications and "don't care" about the "persistence layer" too much in the beginning. It helps getting quick results in a time when things are not at all well defined yet, because you can always very easily drop and re-create your database of your greenfield project.

Unfortunately, most tools that offer this approach do not really help transitioning from the "greenfield project mode" to the more longterm "legacy project mode" where database migrations are essential. In fact, not only are database migrations difficult to achieve in "client model first" approaches, but more importantly, the likelihood of the database model not being well designed is quite high.

Developers pay a high price for the quick win - as always. It is really not a good idea and a lot of more experienced developers who are used to working with legacy, do agree with you: Go database first, and derive your client (e.g. ORM) models from it.

I have written about this topic here, including the advantage of using client model source code generation.

Lukas Eder
  • 211,314
  • 129
  • 689
  • 1,509