Code First Existing Database vs EF Designer to Existing Database

Question

We are starting a new large corporate project. The database will be 100+ tables and we will be using Entity Framework, Web API and MVC.

My question is specifically related to the Entity Framework aspects of the solution. I am trying to make a choice between the following:

• Code first to an existing Database
• EF Designer to an Existing Database (Database First)

I know we can use EF to generate the database from code first or from the EF designer, but we prefer to have full control over the database and develop that in the traditional way, so we have excluded the EF options that allow us to auto-generate the database.

Most of what I can find on the internet relating to Code First deals with creating a new database and then using code migrations. And when the discussions deal with Database first then the discussions favour the EF Designer. Example here: Code-first vs Model/Database-first

My preference is to go with the combination of Code First to an existing database.

The following are my considerations for favouring this option and I'm wondering if there is anything else I need to consider, and whether my assumptions/thoughts are correct.

Code first to an Existing database

• There will be a large number of classes to construct at the start, but we could do the initial generation from the EF Model Wizard.
• The classes could then modified with any custom properties or to remove anything we don't need, rather than the EF Designer that would require us to extend any classes.
• The disadvantage is that any changes to the database would have to be manually added to our classes, unlike using the designer which will allow easy updating.

Edit: I think I was confused in this area. From reading, it appears that the correct way to do Data First is to create partial classes for all the auto generated classes, and then to make any modifications to the partial classes as part of the 'business' layer. My thought has therefore changed from favouring the Code First from Database, to using the EF Designer to existing database and then creating the partial classes.

Answer 1

In any case you'll have to synchronize the EDM (entity data model) and the DB. You have to make sure that the EDM is fully compatible with your database. If not, it will fail, no matter if it's Code First or you use a Model.

The only difference is that:

• using the designer you can do it graphically, and easyly set properties, column names, and so on
• using Code First, you have to set these properties, columns names, data types and so on using conventions, Fluent API or attributes

With Code First the only advantage is that once you've synchronized the Code First model (see "Code First is also an EDM, but somewhat limited") and the database, you can start using Migrations, and evolve your model using them, which later makes it easier to apply changes to the production DB (whenever a new version is released). With graphic model you cannot use migrations, and have to upgrade the Db directly from Visual Studio, or creating SQL DDL scripts by hand.

Code First is also an EDM, but with a few missing functionalities

It doesn't matter if you use Code First or draw a model, an EDM (entity data model) will be generated. If you're used to design databases, probably you'll be more comfortable using the designer. Beware of the notes on EF Core (former EF7) below!.

However, the EDM generated by Code First has a few limitations that the designer doesn't have.

The most outstanding limitations of Code First is that in the designer you can easily map user defined functions from the BD, for example scalar and table value functions, and stored procedures. With Code First there are much more limitations.

in EF 6.1 most of this limitations dissapear, but it's still a bit difficult to make the mappings.(In fact, as of today, 2014, there's only a sample, and a simple Nuget package on how to do it.).

As of march 2017, non-Core EF, i.e. EF 6.1, is no longer being updated. MS will probably solve bugs if they appear, (this was wrong: but don't expect further changes)

New features appeared in 6.2: What's new in EF 6.2, which includes definition of indices with Fluent API, support for Like, support for non-identity DB generated keys, like SEQUENCE and some other changes

Changes on EF Core, former EF7 (as of may 2015)

At this time Microsoft is developing EF 7, but it's also maintaining EF 6.x. The current recommendation is to keep using EF 6 for some time, because EF 7 is not mature enough.

EF 7 is being developed from scratch to overcome the inherited ObjectContext which was posing terrible limitations to implemente new features. But it implements the most widely used DbContext with little changes. So, if you use DbContext you'll have an easy migraiton path to incoming new versions of EF.

However there is a very important change: in EF Core (former EF7) the EDM model dissapears in favor of Code First models. So, if you want to use the technology of today and assure an easy upgrade to new versions, don't use Model First or Database First: use Code First. There are important reasons for Microsoft to have taken this decision: Code First works much better in a team environmet with version control, and allows to work with Migrations. Anyway tou can still see the model in a graphical way (with Power Toools) or use a third party tool to create the model using a designer (several of the current commercial solutions will support this for EF7).

NOTE: Why is much better Code First in team environments? If several team members modify the model it's much easier to merge changes in several code files, than in a big XML file, with lots of lines which defines the model. It's also much harder to understand the changes between versions in this hugh XML file. For medium or big projects, I recommend you to move to Code First ASAP