In Chapter 1 of the first module of my ASP .NET MVC course, I discuss with the students strategies for development and fast database building using Entity Framework. In the consultancies that I do, it is quite common to find the configuration of the Entity Framework being used in a way that unnecessarily complicates the workflow of the development team, and this article seeks to discuss some of these configurations and guide the team to what is most appropriate.
For this article, I’m assuming a Scrum time setup like that of a “chapter”, as described in Spotify’s video about their culture, of up to 8 people. I am also assuming the use of the ASP.NET MVC5 framework along with the latest version of the Entity Framework 6 (at the time of this article, 6.1.3).
In all places I have done consultancy services to date, the best configuration for incrementing the database is the one that uses Automatic Migrations and Data Loss Allowed. Why? Because, in development, it is common (and healthy) to build and destroy the sample database several times. Defects and design problems usually appear at this stage. It is also commonplace for each developer to work on different functionality and implement a whole new set of data, without having to depend on the other developer database additions. Losing data in development is not exactly a problem. If a good data sowing procedure is set up, the loss of test data under development becomes a detail.