May 2011

Volume 26 Number 05

Data Points - Demystifying Entity Framework Strategies: Model Creation Workflow

By Julie Lerman | May 2011

As a data-access technology designed to meet the needs of a variety of development styles, the Microsoft Entity Framework presents developers with a lot of options. Some of these choices need to be made early on in your development cycle and will impact what options you’ll have further along in your development process. In my next three columns, I’ll provide high-level guidance for some of the biggest decisions you’ll need to make with the Entity Framework:

• Code First, Model First or Database First workflows for creating a conceptual model
• Lazy, explicit or eager loading
• Plain Old C# Objects (POCOs) or EntityObjects
• LINQ to Entities or Entity SQL

There are many more design decisions to be made throughout your application, but these questions are the most frequently asked—and often debated—by developers as they begin to implement the Entity Framework into existing or new applications.

I’ll attack the conceptual model creation workflow here and cover the other three topics in the next two columns. My goal is to provide a high-level overview.

Three Options for Creating a Conceptual Model

The Entity Framework relies on a conceptual model of your domain entities, called an Entity Data Model (EDM), and choosing how to create that model is the first decision you’ll need to make. There are three separate workflows to choose from:

• The Database First workflow begins with a legacy database and leverages a wizard to reverse-engineer that database into a conceptual model.
• The Model First workflow begins with an empty slate. You use the visual EDM Designer to design an EDM, then generate database schema from that model.
• The Code First workflow begins with classes that describe your conceptual model. There’s no visual model used with Code First.

Database First: Start with a Legacy Database

In the first iteration of the Entity Framework, we didn’t have all of the options mentioned. The only way to create a model was to reverse-engineer an existing database into an EDM, which we refer to as Database First modeling (see Figure 1).

Figure 1 With Database First, You Reverse-Engineer a Model from a Legacy Database

You’ve probably seen this demonstrated many times, in fact. You open the EDM Wizard, point to an existing database, select which tables, views, stored procedures and user-defined functions you’d like to be represented in the model and click the finish button. Instantly, a model is born. The Database First model starts its life as a virtual reflection of the database (or that subset of the database you selected). With no more effort, developers will already benefit from the Entity Framework. You can write strongly typed queries against this model, and the Entity Framework will execute those queries for you and materialize strongly typed objects from the results. Then, as you work with the results, the Entity Framework tracks the changes and allows you to persist them back to the database simply by calling its SaveChanges command.

That’s going to be all that some developers need from the Entity Framework, but they’re missing out on one of the great benefits of having the model, which is that you can make it look more like your domain—the classes and relationships that define your application—than the database, and then not have to worry about how to get from there back to your database (which the Entity Framework will continue to take care of for you). Model customization is a critical feature of the EDM that many developers overlook and don’t benefit from. You can introduce inheritance hierarchies into the model, reshape entities, combine and split entities, and much more.

 With Database First, you can have the best of both of these worlds: leverage the existing database to get a huge head start with creating your model, then customize that model to better reflect your application domain.

Model First: Start with a Visual Model

You won’t always have a legacy database to start with. Model First lets you design the model directly in the designer and create your database schema based on the model. You can build your entities and their properties, define relationships and their constraints, and create inheritance hierarchies right in the designer. You can specify what properties will become identity keys and even if the database should be responsible for generating their values (see Figure 2).

Figure 2 With Model First, You Design a Model that’s Used to Generate Database Schema

The EDM Designer “Create Database from Model” feature doesn’t actually create a database. What it will do is build SQL that, when executed, will define the schema of a database. This SQL is referred to as Data Definition Language, or DDL.

There are a few non-obvious things to be aware of. Model First was introduced in Visual Studio 2010 and the Microsoft .NET Framework 4. You won’t find the Create Database option in Visual Studio 2008. Also, because it’s a new feature, you’ll need to ensure that the ADO.NET Data provider you’re using (for example, System.Data.Sql) has been updated to provide this capability. The Microsoft SQL Server provider was updated for the .NET 4 release; some of the third-party providers have also been updated.

A behavior to be prepared for is that Model First does not, by default, perform incremental schema updates to your database. When you run the feature, it will create a completely new DDL script that will remove and then recreate all of the database objects. External tools are available to help you modify the database schema rather than overwrite it. Otherwise you’ll want to either back up your data in advance or write a script to regenerate your test data any time you want to modify the model and recreate the database schema.

Visual Studio does provide an extensibility point in the database generation, which you can leverage with the help of the Entity Designer Database Generation Power Pack from Microsoft. You can download it from the Visual Studio 2010 Extension Manager or from visualstudiogallery.com. This extension not only provides a way for you to make incremental changes to the database with Model First, but it also gives you the ability to change the default Table Per Hierarchy inheritance mapping and even create your own customized DDL generation rules.

Code First: Start with Code and Forego a Physical Model

With Database First and Model First, you’ll end up with a physical representation of your EDM along with additional metadata. The raw format of this model is XML. It’s stored in a file with an EDMX extension, and you can work with it in the EDM Designer or the raw XML. At run time, the Entity Framework reads that XML and creates an in-memory representation of the model using specialized classes that represent the metadata—entities, relationships and so on. The Entity Framework runtime works with those objects, not the actual XML file. This metadata is especially critical when the Entity Framework needs to transform model queries into database queries, database results into entity instances, and create database commands for inserts, updates and deletes. Visual Studio will generate your domain classes from the XML to use in your application.

The Entity Framework team has come up with a way to create the needed metadata objects at run time without requiring you to have a physical EDMX file. This is the power behind the third model-creation workflow for the Entity Framework, called Code First. With Code First, rather than creating an EDM, you create your domain classes as you would for any other .NET development. At run time, the Entity Framework will inspect those classes and, using a set of default conventions, build an in-memory model that the Entity Framework runtime can work with. Because your classes won’t always naturally provide the information that the Entity Framework needs to create that model, you can provide additional configuration (using declarative attributes/data annotations or in code using a fluent API) to further describe the model, overriding the conventions mentioned earlier. You can use configuration for a wide variety of model tasks, from identifying primary keys that don’t match Code First conventions to fine-tuning relationships or even specifying how an inheritance hierarchy should be represented.

Like Model First, Code First defaults to the presumption that you aren’t starting with a legacy database, and provides the capability to create that database from the inferred model. Unlike Model First, you can create the database file as well as the schema. With Code First, you still lack a way to persist database data if you modify the model and regenerate the database. However, Code First does have support to detect model and database differences, as well as seed the database with data using database initializers.

You can also use Code First with an existing database. If your class and property names don’t match up to the database, you can add data annotations or configuration through the fluent API to overcome that. Figure 3 shows a class with attributes that will force Code First to provide mappings to the correct table and property names even though the class and fields don’t match exactly.

Figure 3 A Class with Code First Attributes to Ensure the Class Can Correctly Map to an Existing Table

[Table("SalesOrderDetail", SchemaName="SalesLT")]
  public partial class Detail
  {
    // Scalar properties

    [Column(Name = "SalesOrderID")]
    public int OrderId { get; set; }
    [Column(Name = "SalesOrderDetailID")]
    public int DetailId { get; set; }
    public short OrderQty { get; set; }
    public int ProductId { get; set; }
    public decimal UnitPrice { get; set; }
    public decimal UnitPriceDiscount { get; set; }

    public decimal LineTotal { get; set; }
    public System.DateTime ModifiedDate { get; set; }

    // Navigation properties

    public virtual Product Product { get; set; }
    public virtual Order Order { get; set; }
  }

A Decision Tree

The Entity Framework has evolved to support a variety of development styles, but this now forces us to be familiar with the options in order to choose the right approach. If you like to use a UI for your model, then you have the EDM Designer available whether you’re starting with an existing database or using the Model First option. Even then, you can still use the modeler to help make a stake in the ground and then use a template to create Code First classes and drop the visual model. If you’re all about the code and prefer not to be tied to an EDMX file or the visual modeler, Code First will appeal to you (see Figure 4).

Figure 4 The Decision Tree

Starting on the Right Path

Whichever modeling technique you choose—Database First, Model First or Code First—once you’ve created a model, you won’t notice any difference when you begin to query, interact with and persist entities using the Entity Framework runtime by way of the model’s classes. And it’s possible to start with one workflow and switch to another. You can create Code First classes from an EDMX using the DbContext Code Generation template. And, while it’s not quite as easy, you can also create an EDMX from Code First classes.

I’ve provided a high-level view of the choices and what might drive you to choose one over the other, and hopefully I’ve demystified some of the options for you.

In future columns, I’ll talk about other big decisions you’ll face in your Entity Framework applications, which I mentioned at the start of this column: choosing a code-generation strategy for EntityObjects or POCOs, loading related data using eager, lazy or explicit loading, and writing queries using LINQ to Entities or Entity SQL.

Julie Lerman is a Microsoft MVP, .NET mentor and consultant who lives in the hills of Vermont. You can find her presenting on data access and other Microsoft .NET topics at user groups and conferences around the world. She blogs at thedatafarm.com/blog and is the author of the highly acclaimed book, “Programming Entity Framework” (O’Reilly Media, 2010). Follow her on Twitter at twitter.com/julielerman.

Thanks to the following technical expert for reviewing this article: Tim Laverty