Chapter 1. Introducing the ADO.NET Entity Framework

At Microsoft’s November 2009 Professional Developer Conference, the legendary Don Box, a Distinguished Engineer at Microsoft, said, “If you’re a .NET developer Entity Framework is where we’re going. We’re there. Get on board, it’s time.”

Yes, it’s time.

Developers spend far too much of their precious time worrying about their backend database, its tables and their relationships, the names and parameters of stored procedures and views, as well as the schema of the data that they return. For .NET developers, Microsoft’s new Entity Framework changes the game so that you no longer have to be concerned with the details of the data store as you write applications. You can focus on the task of writing those applications, rather than accessing the data.

The ADO.NET Entity Framework has shifted into becoming Microsoft’s core data access platform for building .NET applications. It was released in July 2008 as part of the Visual Studio 2008 Service Pack 1 and .NET 3.5 Service Pack 1, two years after Microsoft announced it at its TechEd 2006 Conference. As a version 1 product, Entity Framework was greeted at first with skepticism, and its adoption was far from sweeping. However, with the release of Visual Studio 2010 and .NET 4 in April 2010, a much improved Entity Framework finally got the attention and excited responses of many developers and .NET teams, who are now quickly jumping aboard.

Although ADO.NET retains its existing data access, as Microsoft’s core data access strategy going forward the Entity Framework will receive the bulk of the innovation and resources from the Business Platform Division (which owns all of the data programmability tasks at Microsoft). It’s an important technology for Microsoft, and one that you should not ignore. Entity Framework is also being integrated into many of Microsoft’s products, whether the product uses Entity Framework to support its own features, such as with Commerce Server 2009’s Multi-Channel Commerce Foundation,[1] or whether the product has support for interacting with the Entity Framework, such as with SQL Server Modeling.

Why do we need a new data access technology? After forcing developers to switch from one data access technology to another—from DAO to RDO to ADO and then to ADO.NET—with ADO.NET Microsoft seemed to have finally settled on a single tool in which developers could invest. With each release of Visual Studio and the .NET Framework, ADO.NET has been enhanced and added to, but has remained backward compatible all along. Our investment has been safe.

And it remains safe, even though it will be stagnant. The Entity Framework is another enhancement to ADO.NET, giving developers an added mechanism for accessing data and working with the results in addition to DataReaders and DataSets.

But Microsoft went as far as it could with the DataSet paradigm. The next step was to enable developers to focus on a domain model while .NET would automate the redundant tasks of database interaction.

In this chapter, you will learn about the critical pieces of the Entity Framework, the Entity Data Model, entity classes, the core .NET APIs, and Visual Studio design tools. You will also learn about how Entity Framework fits in with ADO.NET’s DataSets and LINQ to SQL. Finally, you will learn about many of the changes and additions to Entity Framework in Visual Studio 2010 and .NET 4, and how so many of the pain points in the first version have been eliminated.

The Entity Relationship Model: Programming Against a Model, Not the Database

A central benefit of the Entity Framework is that it frees you from being concerned with the structure of your database. All of your data access and storage is done against a conceptual data model that reflects your own business objects.

With ADO.NET DataReaders and many other data access technologies, you spend a lot of time writing code to get data from a database, read the results, pick out bits of data you want, and push them into your business classes. With the Entity Framework, you no longer query against the schema of a database, but rather against a schema that reflects your own business model. As data is retrieved, you are not forced to reason out columns and rows and push them into objects, because they are returned as objects. When it’s time to save changes back to the database, you have to save only those objects. The Entity Framework does the necessary work of translating your objects back into the rows and columns of the relational store. The Entity Framework does this part of the job for you, similar to the way an Object Relational Mapping (ORM) tool works.

The Entity Framework uses a model called an Entity Data Model (EDM), which evolved from Entity Relationship Modeling (ERM), a concept that has been used in database development for many years.

The Entity Data Model: A Client-Side Data Model

An Entity Data Model (EDM) is a client-side data model and it is the core of the Entity Framework. It is not the same as the database model, which belongs to the database. The data model in the application describes the structure of your business objects. It’s as though you were given permission to restructure the database tables and views in your enterprise’s database so that the tables and relationships look more like your business domain rather than the normalized schema that is designed by database administrators.

Figure 1-1 shows the schema of a typical set of tables in a database. PersonalDetails provides additional information about a Person that the database administrator has chosen to put into a separate table for the sake of scalability. SalesPerson is a table that is used to provide additional information for those who are salespeople.

Schema of normalized database tables

Figure 1-1. Schema of normalized database tables

Working with this data from an application requires queries that are full of inner joins and outer joins to access the additional data about Person records. Or you will access a variety of predefined stored procedures and views, which might each require a different set of parameters and return data that is shaped in a variety of ways.

A T-SQL query to retrieve a set of SalesPerson records along with their personal details might look something like this:

SELECT     SalesPerson.*, PersonalDetails.*, Person.*
FROM       Person
           INNER JOIN PersonalDetails
           ON Person.PersonID = PersonalDetails.PersonID
              INNER JOIN SalesPerson ON Person.PersonID = SalesPerson.PersonID

Imagine that a particular application could have its own view of what you wish the database looked like. Figure 1-2 reshapes the schema.

Person data shaped to match your business objects

Figure 1-2. Person data shaped to match your business objects

All of the fields from PersonalDetails are now part of Person. And SalesPerson is doing something that is not even possible in a database: it is deriving from Person, just as you would in an object model.

Now imagine that you can write a LINQ query that looks like this:

from p in People.OfType<SalesPerson>() select p

In return, you will have a set of SalesPerson objects with all of the properties defined by this model (see Figure 1-3).

The SalesPerson object

Figure 1-3. The SalesPerson object


LINQ exists only in the C# and Visual Basic languages. With the Entity Framework there is another way to express queries, which not only allows you to use other languages, but also provides additional benefits that you can take advantage of as necessary. It’s called Entity SQL, and you will learn much more about it and LINQ to Entities in Chapters 3 through 5.

This is the crux of how the Entity Framework can remove the pain of having not only to interact with the database, but also to translate the tabular data into objects.

.NET is but one tool that uses an EDM. The next version of SQL Server will use an EDM for Reporting Services and you will soon begin to see other Microsoft applications that will adopt the EDM concept as well. In fact, you will find that model-driven development in general is getting more and more attention from Microsoft.

When working with the Entity Framework, you will implement an EDM that is particular to the Entity Framework. In the Entity Framework, an EDM is represented by a single XML file at design time that is split into a set of three XML files at runtime, only one of which represents a conceptual model. The other two provide metadata that enables Entity Framework to interact with a database. You’ll learn much more about this metadata in Chapter 2.

Entities: Blueprints for Business Classes

The items described by an EDM are known as entities. Classes that are generated from the model entities, along with their instantiated object, are also referred to as entities but are often called entity classes or entity objects. The generated entity classes differ from typical business classes in that they have properties but no behavior apart from methods to enable change tracking.

Figure 1-4 shows the class diagram for the Person and SalesPerson classes that the model shown in Figure 1-2 would generate automatically. Each class has a factory method (e.g., CreatePerson) as well as methods used to notify the Entity Framework when a property changes.

Class diagrams for the Person and SalesPerson entities

Figure 1-4. Class diagrams for the Person and SalesPerson entities

With the classes the Entity Framework generates, you can add your own business logic, pull the results into business objects of your own, and even link your business objects to the EDM, replacing the generated classes. But by definition, the entity classes describe only their schema.

In addition to being able to reshape the entities in a data model as with the inheritance hierarchy shown in Figure 1-2, you can define relationships between entities. Figure 1-5 adds a Customer entity to the model which also derives from Person as well as an Order entity. Notice the relationship lines between SalesPerson and Order, showing a one-to-many relationship between them. There is also a one-to-many relationship between Customer and Order.

SalesPerson and Customer entities, each with a relationship to Order entities

Figure 1-5. SalesPerson and Customer entities, each with a relationship to Order entities

When you write queries against this version of the model, you don’t need to use JOINs. The model provides navigation between the entities.

The following LINQ to Entities query retrieves order information along with information about the customer. It navigates into the Customer property of the Order to get the FirstName and LastName of the Customer.

from o in context.Orders
select new {o.OrderID,o.OrderNumber,o.Customer.FirstName,o.Customer.LastName}

Once that data is in memory, you can navigate through each object and its properties, such as myOrder.Customer.LastName, just as readily.

The Entity Framework also lets you retrieve graphs, which means you can return shaped data such as a Customer with all of its Order details already attached.

These are some of the major benefits to querying against a data model, rather than directly against the database.

The Backend Database: Your Choice

You may have noticed that I have not mentioned the actual data store that owns the data being queried. The model doesn’t have any knowledge of the data store—what type of database it is, much less what the schema is. And it doesn’t need to.

The database you choose as your backend will have no impact on your model or your code.

The Entity Framework communicates with the same ADO.NET data providers that ADO.NET already uses, but with a caveat. The provider must be updated to support the Entity Framework. The provider participates in reshaping the Entity Framework’s queries and commands into native queries and commands. All you need to do is identify the provider and a database connection string so that the Entity Framework can get to the database.

This means that if you need to write applications against a number of different databases, you won’t have to learn the ins and outs of each database. You can write queries with the Entity Framework’s syntax (either LINQ to Entities or Entity SQL) and never have to worry about the differences between the databases. If you need to take advantage of functions or operators that are particular to a database, Entity SQL allows you to do that as well.

Database Providers

Microsoft’s SqlClient APIs that are included with Visual Studio 2008 SP1 and Visual Studio 2010 support the Entity Framework. They will allow you to use SQL Server 2000, 2005, and 2008. You can use the full or Express version of SQL Server 2005 and 2008 and the full version of SQL Server 2000. Note that the Entity Data Model Designer cannot interact with SQL Server 2000. This is not a limitation of Entity Framework’s design tools but Visual Studio 2010 itself. None of Visual Studio’s tools recognizes SQL Server 2000. However, the Entity Framework runtime can. SQL Server CE version 3.5 and 4 support the Entity Framework as well. Check out the July 7, 2010, blog post from the SQL Server CE team about SQL Server Compact 4 at

At the time of this writing, a host of other providers are available—and more are on the way—that will allow you to use Oracle, IBM databases, SQL Anywhere, MySQL, SQLite, VistaDB, and many other databases. The providers are being written by the database vendors as well as by third-party vendors. Many of these providers were written for .NET 3.5. There is only one critical feature that they will not support until they have been updated to .NET 4: a feature called model first, which you will learn about in Chapter 25.


Microsoft lists providers on the “ADO.NET Data Providers” page of the Data Developer Center at


Microsoft provides guidance for developers who want to build Entity Framework support into their database providers. I will not be covering this topic in this book. You can see EF team blog posts about writing providers at

Access and ODBC

A provider that supports the Entity Framework needs to have specific knowledge about the type of database it is connecting to. It needs to be aware of the available functions and operators for the database, as well as the proper syntax for native queries. Open Database Connectivity (ODBC) providers provide generic access to a variety of databases, including Access, and cannot furnish the necessary database particulars to act as a provider for the Entity Framework. Therefore, ODBC is not a valid provider for the Entity Framework. Unless someone creates a provider specifically for Access, you won’t be able to use it with Entity Framework applications. Microsoft does not have plans to build an Access provider, because the demand is too low.

Entity Framework Features: APIs and Tools

In addition to the EDM, the Entity Framework provides a set of .NET runtime APIs that let you write .NET applications using the EDM. It also includes a set of design tools for designing the model. Following is a synopsis of the Entity Framework’s key features.


Although the Entity Framework is designed to let you work directly with the classes from the EDM, it still needs to interact with the database. The conceptual data model that the EDM describes is stored in an XML file whose schema identifies the entities and their properties. Behind the conceptual schema described in the EDM is another pair of XML files that map your data model back to the database. One is an XML file that describes your database and the other is a file that provides the mapping between your conceptual model and the database.

During query execution and command execution (for updates), the Entity Framework figures out how to turn a query or command that is expressed in terms of the data model into one that is expressed in terms of your database. It does this by reading the metadata.

When data is returned from the database, it uses the metadata to shape the database results into the entities and further materializes objects from those results.

Entity Framework acquires the ability to use an in-memory model with a feature called code first that is part of the Entity Framework Community Technical Preview (CTP). It is not yet part of Entity Framework and must be downloaded separately. Code first allows you to work solely with classes, and the necessary XML metadata is generated in memory on the fly at runtime. You’ll learn more about this feature in Chapter 25, but be aware that at the time of this book’s publication, code first is still a CTP and is not yet fully developed.

Entity Data Model Design Tools

The screenshots in Figures 1-2 and 1-3 are taken from the EDM Designer. It is part of Visual Studio and provides you with a way to work visually with the model rather than tangle with the XML. You will work with the Designer right away in Chapter 2, and you’ll learn how to use it to do some more advanced modeling, such as inheritance, in Chapter 14 and “model-first” design in Chapter 25. You will also learn about the Designer’s limitations, such as the fact that it does not support all of the features of the EDM. With some of the less frequently used EDM features, you’ll have to work directly with the XML after all. In Chapter 2, you will get a look at the XML and how it relates to what you see in the Designer so that when it comes time to modify it in Chapter 15, you’ll have some familiarity with the raw schema files.


In Visual Studio 2010, the Designer supports many more features than it did in Visual Studio 2008 SP1. However, as you will see in Chapters 14 and 15, there are still some things you will need to do manually.

The Designer also allows you to map stored procedures to entities, which you’ll learn about in Chapter 6. If you are coming from Visual Studio 2008 SP1, you’ll find that the Designer’s stored procedure support has been greatly improved in Visual Studio 2010.

Another notable feature of the Designer is that it will let you update the model from the database to add additional database objects that you did not need earlier or that have been added to the database since you created the model.

Database-first design

One of the EDM design tools is the Entity Data Model Wizard. It allows you to point to an existing database and create a model directly from the database so that you don’t have to start from scratch. Once you have this first pass at the model, you can begin to customize the model in the Designer.

Model-first design

Not every development project begins with a legacy database. One of the new features in Visual Studio 2010 is the ability to create a model directly in the Designer and then generate database schema based on that model. Although we’ll focus on a model created using database-first design through most of this book, you’ll get a chance to drill into model-first design, as well as some additional Designer features, in Chapter 25.

Code generation

Once you have a model to define your domain entities, you’ll need classes to represent them at runtime. The Designer automatically generates those classes for you from the model. However, we’ve gained another critical feature in Visual Studio 2010. Rather than using the proprietary code generator that was written for Entity Framework in Visual Studio 2008 SP1, the classes are generated using Visual Studio’s Text Template Transformation Toolkit (T4). Not only does this provide a more commonly known mechanism for code generation, but also you can much more easily customize the provided templates to define exactly how you would like classes to be generated from your model. You’ll learn about the code generation capabilities beginning with Chapter 11 and work further with T4 customization in later chapters. There are some scenarios where you will be able to skip code generation completely and simply use your own classes.

Object Services

The Entity Framework runtime’s most prominent feature set and that which you are likely to work with most often is referred to as Object Services. Object Services sits on top of the Entity Framework stack, as shown in Figure 1-6, and provides the functionality needed to work with objects that are based on your entities. Object Services provides a class called EntityObject and can easily manage any class that inherits from EntityObject. This includes materializing objects from the results of queries against the EDM, keeping track of changes to those objects, managing relationships between objects, and saving changes back to the database.

In between querying and updating, Object Services provides a host of capabilities to interact with entity objects, such as automatically working with a lower level of the Entity Framework to do all of the work necessary to make calls to the database and deal with the results. Object Services also provides serialization (both XML and binary).

The Entity Framework stack

Figure 1-6. The Entity Framework stack

POCO Support

One of the most important runtime enhancements in .NET 4 is the ability for the Entity Framework to manage entities that do not inherit from EntityObject. This is Entity Framework’s new POCO (Plain Old CLR Objects) support, and you will learn much more about this feature beginning with Chapter 13. POCO support is critical to enable a variety of different programming styles. With POCO entities, developers can more easily build unit tests as well as persistent ignorant entity classes. These capabilities are crucial to developers who follow the coding patterns recommended by domain-driven and agile development. These same developers were unable to use the Entity Framework in .NET 3.5. Now Entity Framework embraces a wider population of the development community.

Change Tracking

Once an entity object has been instantiated, either as a result of data returned from a query or by instantiating a new object in code, Object Services can keep track of that object. This is the default for objects returned from queries. When Object Services manages an object, it can keep track of changes made to the object’s properties or its relationships to other entity objects.

Object Services then uses the change-tracking information when it’s time to update the data. It constructs Insert, Update, and Delete commands for each object that has been added, modified, or deleted by comparing the original values to the current values of the entity. If you are using stored procedures in conjunction with entities it will pass the current values (and any original values specifically identified) to those procedures.

Relationship Management and Foreign Keys

Relationships are a critical piece of the EDM; however, in .NET 4, an important new feature was added: foreign key support. In a classic Entity Relationship Model, foreign keys are not exposed in the conceptual model. Entity Framework followed this paradigm in .NET 3.5 SP1, but we developers still wanted access to those foreign key values for many reasons. In fact, in the first edition of this book, I showed a variety of ways to go “under the covers” to get and set foreign keys. Now Entity Framework supports having the foreign keys in the conceptual model. However, for backward compatibility, you can still use the former mechanism which, because of the lack of foreign keys, instantiates relationships as objects.


I will not spend a lot of time focusing on the older style of building relationships in this book as it is not the default and will be used minimally. If you need in-depth guidance on how to work with relationships when the foreign key is not available in the conceptual model, I recommend that you read the first edition of this book.

As you will find, especially in Chapter 19, which dives deep into relationships, even with foreign keys, you will need to have a very good understanding of how relationships work. Some of the rules of engagement when working with related data are not very intuitive, and you can write code that will raise plenty of exceptions, or worse, will return invalid results, if you break these rules. Chapter 19 will provide insight into relationships in the EDM so that you will be able to work with them in an expert manner.

Data Binding

You can use entities in many .NET data binding scenarios. In Windows Forms and WPF, you can use entities as a data source for data-bound controls or as the data source for BindingSource controls, which orchestrate the binding between objects and UI controls on the form. Chapter 9 provides a well-informed walkthrough for using entities with BindingSource controls to edit and update data. Chapter 26 focuses on separating the data access and other business logic from the user interface to provide better architecture for your applications.

Chapter 9 also provides a walkthrough for data-binding entities in Windows Presentation Foundation (WPF) applications. Visual Studio 2010 introduced a host of enhancements for data binding in WPF, and you’ll benefit greatly from these when data-binding with entities.

For ASP.NET, there is a DataSource control called EntityDataSource that works in a similar way to the ASP.NET SqlDataSource and LinqDataSource controls, allowing you to declaratively bind entity objects to your user interface. Chapter 12 is all about using EntityDataSource. You’ll also get a quick look at binding with ASP.NET Dynamic Data in that chapter.

n-Tier Development

Entity Framework made significant advancements for n-tier development in .NET 4. In .NET 3.5 SP1, it was just too hard; as such, in the previous edition of this book I devoted a lot of pages to hacks and workarounds. Now we can benefit greatly from not only the foreign keys but also a slew of state management methods that make working across processes much simpler. Additionally, POCOs make n-tier development easier to achieve as you’ll see in the final chapters of this book.

For layered applications, Chapter 24 and Chapter 25 focus on pulling all of the data access tasks out of the ASP.NET user interface, and you’ll see a WPF application, an ASP.NET Web Forms application, and an ASP.NET MVC application using various patterns to separate your logic.


EntityClient is the other major API in the Entity Framework, though one that you are less likely to work with directly. It provides the functionality necessary for working with the store queries and commands (in conjunction with the database provider) connecting to the database, executing the commands, retrieving the results from the store, and reshaping the results to match the EDM.

You can work with EntityClient directly or work with Object Services, which sits on top of EntityClient. Not only is EntityClient able to perform queries, but it does this on behalf of Object Services. The difference is that when you work directly with EntityClient, you will get tabular results (though the results can be shaped). If you are working with Object Services, it will transform the tabular data created by EntityClient into objects.

The tabular data returned by EntityClient is read-only. EntityClient is well suited for reporting and moving data from one persistence mechanism to another. Only Object Services provides change tracking and the ability to save changes back to the data store.

The Entity Framework and WCF Services

You can use the Entity Framework anywhere you can use ADO.NET, including web services and WCF services. Chapters 17 and 18 walk you through the process of providing services for EntityObject entities and POCO entities.

In these chapters, we’ll also take a look at WCF Data Services, WCF RIA Services, and a specialized POCO template called Self-Tracking Entities, which provides client-side change-tracking capabilities to entities, thereby allowing a simpler way to send changes to WCF services and then persist them to the database.

What About ADO.NET DataSets and LINQ to SQL?

The Entity Framework is only the latest addition to the ADO.NET stack. How does that impact existing code that uses DataSets and DataReaders or LINQ to SQL? Can you continue to write new code using these technologies?


DataSets and DataReaders are not going away. All of your existing investment will continue to function and you can continue to use this methodology of retrieving data and interacting with it. The Entity Framework provides a completely different way to retrieve and work with data. You would not integrate the two technologies—for example, using the Entity Framework to query some data, and then pushing it into a DataSet; there would be no point. You should use one or the other. As you learn about the Entity Framework, you will find that it provides a very different paradigm for accessing data. You may find that the Entity Framework fits for some projects, but not others, where you may want to stick with DataSets.

The Entity Framework uses DataReaders as well in the form of an EntityDataReader, which inherits the same DbDataReader as SqlDataReader. This is what a query with EntityClient returns. In fact, you’ll find that the code querying the EDM with EntityClient looks very similar to the code that you use to query the database directly with ADO.NET. It uses connections, commands, and command parameters, and returns a DbDataReader that you can read as you would any other DataReader, such as SqlDataReader.

Some ADO.NET tools that are not available with the Entity Framework are query notification and ASP.NET’s SqlCacheDependency. Additionally, ADO.NET’s SqlBulkCopy requires a DataReader or DataSet to stream data into the database; therefore, you cannot do client-side bulk loading with the Entity Framework. The Entity Framework does not have an equivalent to ADO.NET’s DataAdapter.BatchUpdate. Therefore, when the Entity Framework saves changes to the database, it can send only one command at a time.


LINQ to SQL and the Entity Framework look similar on the surface. They both provide LINQ querying against a database using a data model.

A frequently asked question is: why did Microsoft create two similar technologies? LINQ to SQL evolved from the LINQ project, which came out of team working with language development. The Entity Framework was a project of the Data Programmability team and was focused on the Entity SQL language. By the time each technology had come along far enough that it was being shown to other teams at Microsoft, it was clear that Microsoft had two great new technologies that could target different scenarios. The Entity Framework team adapted LINQ to work with entities, which confused developers even more because LINQ to Entities and LINQ to SQL look so much alike.

LINQ to SQL eventually was brought into Microsoft’s Data Programmability team, and in November 2008 the team announced that because the technologies target the same problems, going forward they would focus on developing the Entity Framework, which supports multiple databases and aligns with many of Microsoft’s upcoming technologies through its use of an Entity Data Model. However, they will continue to maintain and tweak LINQ to SQL. This is not a happy situation for many developers who have made an investment in LINQ to SQL. Microsoft is committed to maintaining LINQ to SQL in ADO.NET and has made no statements regarding deprecating it. It has also promised to provide a migration path from LINQ to SQL to the Entity Framework and will recommend the Entity Framework over LINQ to SQL in future programmer guidelines.

Entity Framework Pain Points Are Fading Away

In the first edition of this book, Chapter 1 listed two pages of pain points. Their section titles were “The Entity Framework Designer” (which focused on the lack of support for stored procedures and other EDM features), “Challenges with Change Tracking Distributed Applications,” “Domain-Driven Development,” and “Unit Testing.” I’m very happy to have removed every one of these sections thanks to the great improvements that have been made in .NET 4 and Visual Studio 2010.

There are still definitely a lot of nits to pick, however. The model would benefit from support for things such as unique foreign keys, table-valued functions, enhanced many-to-many relationships, and a problem that is much more than a nit: support for very large models.

Entity Framework’s state management and relationship management still have a lot of behavior that is not intuitive and will certainly bite you if you don’t study up on it. Take a look at Chapter 19 for a good study guide.

This book spends plenty of time looking into the depths of the Entity Framework runtime to show you how to get around some of these limitations, and attempts to point out potholes, hiccups, and omissions.

Users of more mature ORM tools continue to have complaints about Entity Framework as well, such as the difficulty of providing internal transactions (database transactions, however, are supported). But if you look around the marketplace, even Entity Framework’s staunchest competitors are getting on board and leveraging their experience to provide advanced tools for working with Entity Framework. The principal player, NHibernate, created a wonderful database profiling tool for Entity Framework, and LLBLGen Pro has built a powerful designer for Entity Framework that takes a very different approach for managing an Entity Framework EDM and its metadata (

Programming the Entity Framework

As you read through this book, you will gain experience in designing EDMs and using the Entity Framework to write applications, as well as dig deep into the APIs to learn how to manipulate entity objects and have granular control over much of their behavior. A lot of functionality is very accessible, and there’s a lot of hidden power. You will learn what’s under the covers so that you can realize the true benefits of the Entity Framework.

Even as I wrap up this edition of Programming Entity Framework, I look forward to future versions of the framework as it continues to evolve.

Get Programming Entity Framework, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.