ADO.NET Entity Framework/Entity Data Model Questions and Answers
Last Updated: April 2010
Q: What is the ADO.NET Entity Framework?
A: The Entity Framework gives you a strongly-typed LINQ data access experience over relational databases (called LINQ to Entities). The Entity Framework makes it easier to work with your data because it moves the data model up from the physical structure of relational tables to a conceptual model that accurately reflects common business objects.
To be specific, the Entity Framework introduces an Entity Data Model (EDM) within the familiar ADO.NET environment, allowing developers to map entities to relational data. This enables developers to reason about and write queries in terms of the EDM rather than the logical schema of tables, joins, foreign keys, and so on. Many enterprise systems have multiple applications/databases with varying degrees of normalization, different schema styles depending on the group that developed it, and different naming conventions for tables and columns. Furthermore, in complex systems the entities of interest may be scattered across multiple rows in multiple tables, and changes to the logical schema can be painful to track within applications.
By adding an additional level of abstraction, the EDM insulates the developer from the low level details of the logical model, and frees them to focus on the essential aspects of the application/problem at hand. This also helps to isolate applications from naming as well as structural changes of the storage schema and allows the application to be portable to most SQL databases. The Entity Framework can be used to provide a common data model across high-level functions such as data query and retrieval services, reporting, synchronization, caching, replication, visualization, and Business Intelligence (BI).
For more information, see Introducing the Entity Framework.
Q: Why use EDM? How does the EDM help?
A: The Entity Framework enables developers to reason about and write queries in terms of the EDM model rather than the logical schema of tables, joins, foreign keys, and so on. Many enterprise systems have multiple applications/databases with varying degrees of normalization, different schema styles depending on the group that developed it, and different naming conventions for tables and columns. Furthermore, in complex systems the entities of interest may be scattered across multiple rows in multiple tables, and changes to the logical schema can be painful to track within applications. By adding an additional level of abstraction, the EDM insulates the developer from the low level details of the logical model, and frees them to focus on the essential aspects of the application/problem at hand. For more information, see Introducing the Entity Framework.
Q. What’s New in the ADO.NET Entity Framework in .NET 4.0?
A: We listened to a great deal to customer feedback and responded with significant investments including:
- POCO (Plain Old CLR Object) support
- Table Value Functions
- Better foreign key support
- T4 code generation
- SQL Methods
- Better Stored Proc support
- Singularization / Pluralization with the Visual and Command Line Tools
- Database Generation from the model
- Better N-Tier API support
We are also actively working to address new asks such as concepts like model-defined functions in this release.
Information on all of these topics can be found in What’s New in ADO.NET and were covered in the PDC 2009 session Evolving ADO.NET Entity Framework in .NET 4 and Beyond by Shyam Pather and Chris Anderson.
Q: Will API Changes and additions in .NET 4 break applications that are built using .NET 3.5 SP1 of the Entity Framework?
A:No. The design of the .NET framework ensures that different versions of the same technology do not and will not interfere with existing versions. Of course, as is common in developer frameworks, some new features will require calling a new API, but not at the expense of the existing API. This enables you to choose to call new features which appear in successive versions based on the value those features provide.
Q. What’s New in LINQ to SQL in .NET 4.0? Or is LINQ to SQL a dead technology?
In .NET 4.0, we made a number of performance and usability enhancements in LINQ to SQL, as well as updates to the class designer and code generation.
Moving forward, Microsoft is committing to supporting LINQ to SQL as well as the Entity Framework as important parts of the .NET Framework; adding new features based on customer needs. We do, however, expect that the bulk of our overall investment will be in the Entity Framework, as this framework is built around the Entity Data Model (EDM). EDM represents a key strategic direction for Microsoft that spans many of our products, including SQL Server, .NET and Visual Studio. EDM-based tools, languages and frameworks are important technologies that enable our customers and partners to increase productivity across the development lifecycle and enable better integration across applications and data sources.
Q: How does the Entity Framework relate to LINQ to SQL?
A: LINQ to SQL provides for a 1:1 mapping from the application into the relational structures of a SQL Server database. The Entity Framework and LINQ to Entities, on the other hand, provides for building a conceptual model that abstracts the relational structures of SQL Server and many other kinds of databases (for which an ADO.NET Data Provider is available).
LINQ to SQL is thus viewed as a simple way to get objects in and out of a database, and tends to shine when the object model and the database model can be the same (such as when an application wants to model foreign keys as first-class concepts in the object model).
The Entity Framework is targeted at a broader vision of data modeling and database-agnostic development. The Entity Framework has a development experience just as simple as LINQ to SQL, but allows developers to program against conceptual entities that more directly serve the problems being solved in an application, rather than programming against the shape of the database. An “order” within a business application, for example, is a singular concept from the application’s point of view, but its information may be spread across many different database tables. To program against the conceptual “order” entity is thus far simpler than working against those tables directly.
The Entity Framework also works well when you want to have a first-class data model (separate from code), when developing applications that can target other databases in addition to Microsoft SQL Server, and potentially for working with multiple databases that may have a different underlying shape but can nevertheless be abstracted into an identical conceptual model.
The Entity Framework is also the foundation for a set of future investments like Reporting over an EDM model, integration, sync, and offline data access.
Q: What is Microsoft’s recommendation for data access?
A: Microsoft recommends that new applications use the Entity Framework as new features will continue to appear in that technology. Existing applications that use LINQ to SQL can continue to do so, with the understanding that most future developments of the .NET data stack will come through the Entity Framework.
Q: Where can I find guidance if I want to migrate from LINQ to SQL to the Entity Framework?
A: We have migration guidance in a blog series on http://blogs.msdn.com/adonet that shows how to migrate between the current shipping versions of LINQ to SQL and LINQ to Entities. As we continue to enable the LINQ to SQL experiences in LINQ to Entities we expect that migration will become easier, however since the abstractions are different, migration will likely require some level of rework of one’s application.
Q: Does LINQ replace ADO.NET?
A: No. LINQ is a common way to integrate queries for all types of data into .NET managed programming languages. ADO.NET provides implementations of LINQ directly against Microsoft SQL Server schemas (LINQ to SQL and LINQ to Entities), 3rd party ADO.NET Data Providers (LINQ to Entities), and the ADO.NET DataSet (LINQ to DataSet).
Q. What is “code-only”? What is the mapping story around “code-only”?
A. Code Only is a future feature for the Entity Framework that has been released as a CTP. Code Only is not part of the .NET Framework 4 nor Visual Studio 2010, but rather a feature we are working on for a future release of the Entity Framework. The current CTP can be downloaded from the Data Developer Center on MSDN.
Code Only allows you to use the Entity Framework using POCO entities without an EDMX file. For programmers who prefer a code centric experience, Code Only allows developers to focus on writing classes and entities and generates a data access layer and database behind it by convention. Code Only makes this easier by generating the database as well as default mappings and offers the ability to change the default mapping if needed using configuration.
Code Only provides two ways to map – Mapping by Convention and configuring the default mapping.
Mapping by Convention – Code Only infers a default mapping following Table-per-Hierarchy inheritance strategy. This means that if there is an inheritance hierarchy , one table is created for an inheritance hierarchy and a discriminator is used to specify the type. For example, if Manager inherits from Employee which inherits from Person, one Person table is created and a discriminator column holds whether the record is a Manager or Employee. Column names match with property names. This offers the best performance.
Configuration – Code Only also allows for changing the default mapping. For example, if we want a different table name or different columns or want to denote facets (like identity or MaxLength) or specifying a different inheritance strategy like Table-per-Type. For more details, please refer to the Entity Framework Design blog.
Q. What is Microsoft’s n-tier story for data access?
A. There are a few established patterns (Data Transfer Objects, Change Tracking, Self-Tracking Entities, etc.) for building an n-tier application, each with strengths and weaknesses. Microsoft provides a range of technologies to facilitate implementing n-tier applications including Data Services, Entity Framework Self-Tracking Entities and .NET RIA Services.
Q: What is the recommended path forward for customers using LINQ to SQL?
A: If customers are currently using LINQ to SQL there are a few questions they should ask:
- Is LINQ to SQL currently meeting the needs of the application?
- Do I care about introducing multiple database vendor support or using the data model of the application for things like Reporting and Offline?
- Do I hope to leverage new integration of the data access stack across .NET and broader Microsoft technologies?
If #1 is true, then you should be just fine staying with LINQ to SQL. You can rest assured that we will continue to service the product and make some tactical innovation. If, however, you want to leverage future innovations (answering yes to points 2 or 3) you may want to look at moving to the Entity Framework.
Q: Why did the Entity Framework introduce a new language EntitySQL as well as LINQ to Entities?
A: LINQ is applicable for situations where classes exist and one can express all queries at design / compile time. The Entity Framework is built in essentially two pieces:
- A new ADO.NET provider (Entity Client) which requires a text-based query language (EntitySQL)
- An Object Layer which can leverage LINQ but may
also use EntitySQL for scenarios such as:
- Late bound queries or dynamic query formulation, even the LINQ data source required a text based representation and LINQ is only compile time
- The ability to create projections and anonymous types over models where class generation is not practical
Q. Has Microsoft addressed the EDM concerns raised in the vote of no-confidence ?
A: It has been gratifying to see the level of interest that customers have in the Entity Framework and the potential that they see it having in the mid-tier for helping to solve so many of the problems that they are working on. The team has been working with a core group of the developer community throughout much of our product lifecycle, and we have heard the concerns from this group previously. Further, we understand the concerns and most if not all have been addressed in Visual Studio 2010 and .NET 4.0.
Q: How have you addressed these concerns?
A: In Visual Studio 2010 we’ve addressed many of the concerns including added support for POCO, foreign keys, model first development, better N-Tier support, and improved Test-Driven Development and Domain-Driven Developer support.
The Entity Framework team will continue to work hard to address community concerns and support additional scenarios in future versions of the product. We have been looking at various options to ensure that the design of Entity Framework truly reflects the requirements of the day to day challenges that our developer community faces when building real-world applications and services and will continue to do so.
One of the ways that we are doing this is by being as transparent as possible in our design process. The approach we are taking is similar to what we successfully piloted on the Astoria Team blog during the development of Data Services which shipped in .NET 3.5 SP1, and enables community members that are interested in the Entity Framework to follow the design topics as we discuss them, and have the opportunity to provide feedback during the time where we as a team are actively discussing a certain aspect of the product, and before we have made a final decision on implementation.
For more technical Frequently Asked Questions check out http://blogs.msdn.com/dsimmons/pages/entity-framework-faq.aspx