The information in this post is out of date.

Visit msdn.com/data/ef for the latest information on current and past releases of EF.

For Code First to a New Database see http://msdn.com/data/jj193542

For Code First to an Existing Database see http://msdn.com/data/jj200620


 

We recently announced the upcoming release of EF 4.1 which includes support for the Code First approach to EF development. This name fits nicely into the three approaches supported by the Entity Framework: Database First, Model First, and Code First. However, it can be a little misleading in that using Code First does not always mean writing your code first.

Database First

The idea behind Database First is that you start with an existing database and use tools (such as the EF Designer in Visual Studio) to generate C# or VB classes from the database. You can modify the classes that are created and the mappings between the classes and the database through the EF designer, or even, if you are feeling brave, through modification of the underlying XML. The key to this approach is that the database comes first and the code and model come later.

Model First

The idea behind Model First is that you start with a blank canvas and then design an Entity Data Model, again using the EF Designer. This model can then be used to generate a database and also to generate C# or VB classes. The key to this approach is that the model comes first and the code and database come later.

Code First generating a database

In the original prototypes of Code First it was actually called Code Only. This was because the only thing that you needed to write was code—the model and the database were created for you. This is the approach we have demoed at conferences and have shown in walkthroughs, etc.

This approach can also be considered a model first approach depending on how you think about your model. The Model First approach described above is for people who like to create an Entity Data Model using a visual designer. However, many developers instead choose to model their application domain using just the code. This approach is often associated with Domain Driven Design (DDD) where the domain model is represented by the code. So, depending on how you view modeling and how you want to represent your model, you may also consider Code First to be a model first approach.

Having Code First generate your database for you is certainly a very powerful approach and we see a lot of people using it, but if it doesn’t work for you then read on!

Code First with an existing database

Imagine you have an existing database and maybe your DBA doesn’t even let you modify that database. Can you still use Code First? The answer is “Yes!” and we are seeing lots of people doing this. Furthermore, this isn’t just an afterthought; Code First has been specifically designed to support this.  The steps are very simple:

  • Make sure your DbContext knows how to find your existing database. One way to do this is to put a connection string in your config file and then tell DbContext about it by passing “name=MyConnectionStringName” to the DbContext constructor. See this post for more details.
  • Create the classes that you want to map to your database.
  • Add additional mapping using data annotations or the Code First fluent API to take care of the places where the Code First conventions need to be overridden to get correct mappings.

This approach is essentially a database first approach, but using code for the mapping instead of a visual designer and XML. We hope to make a T4 template available that would start from an existing database and do the above steps for you—we’d like to hear from you if you would find such a template useful.

Code First != DbContext

The first time most people see DbContext is when using Code First. However, DbContext can also be used together with an EDMX file for traditional Database First and  Model First development. The T4 templates that shipped with CTP5 and that will ship as part of EF 4.1 create a context class derived from DbContext. This is not a Code First context and it will not build a model from data annotations or fluent API calls. Instead it loads the EDMX file at runtime (just like ObjectContext does) and uses the mappings defined in that file. This gives you the improved API surface of DbContext while maintaining the Database First or Model First approach.

It is also possible to use Code First to create an ObjectContext instead of a DbContext. However, we generally don’t recommend that you use this approach.

So is Code First right for me?

The bottom line on whether Code First is right for you depends on how you like to create and store your C#/VB classes and the mapping between those classes and the database. If you like to use code for this, then Code First is probably for you. This is true even if you don’t want the code to create the database, possibly because it already exists and/or is locked down by your DBA.

If you prefer a visual designer and XML files, then Database First or Model First is probably better for you.

As always we would love to hear any feedback you have by commenting on this blog post.

For support please use the Entity Framework Pre-Release Forum.

Arthur Vickers
Developer
ADO.NET Entity Framework