Downloaded 315 times
Uploaded byEric Nelson
Entity Framework Overview
This document discusses the evolution of data access from 1990 to 2010, focusing on object-relational mapping (ORM) techniques. It provides an overview of ORM as an abstraction technique for working with relational data as objects. The document outlines several ORM options available for .NET developers and describes Microsoft's strategic ORM technologies - LINQ to SQL and the ADO.NET Entity Framework. It provides details on Entity Framework's Entity Data Model and how to consume an EDM to query and manage data.
More Related Content
Similar to Entity Framework Overview
![[BDD 2025 - Mobile Development] Mobile Engineer and Software Engineer: Are we...](https://cdn.slidesharecdn.com/ss_thumbnails/md-mobileengineerandsoftwareengineerarewestillrelevantsidiqpermana-251127010650-55224ef1-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Full-Stack Development] Agentic AI Architecture: Redefining Syste...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-agenticaiarchitectureredefiningsystemcommunication-251124030838-e6c70cc2-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Mobile Development] Crafting Immersive UI with E2E and AGSL Shade...](https://cdn.slidesharecdn.com/ss_thumbnails/md-craftingimmersiveuiwithe2eandagslshaderveronicaputrianggraini-251124030840-0c677f44-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Artificial Intelligence] AI for the Underdogs: Innovation for Sma...](https://cdn.slidesharecdn.com/ss_thumbnails/ai-aifortheunderdogsinnovationforsmallbusinesses-251124030839-72a599a4-thumbnail.jpg?width=640&height=640&fit=bounds)
Editor's Notes
- #5 Estimated Time: 6 minutesTalking Points: When we talk about the Entity Framework, we’re actually talking about two things: The Entity Data Model (EDM) The Entity Framework It’s important to delineate the two as separate, but complementing technologies The EDM is a set of layers that make up your application’s model, as well as it’s mapping to an underlying data store. Made up of three files: CSDL (Conceptual Schema Definition Language) MSL (Mapping Specification Language) SSDL (Storage Schema Definition Language) This separation of concerns allows great flexibility: Model your application the way you want regardless of the state/structure of its underlying data store Normalize your database as much as you need without worrying about affecting the interface of the application’s object model The EDM represents a re-useable application model that can be leveraged from within many applications/environments and persisted across numerous databases. The Entity Data Model is RDMS agnostic, and numerous database vendors are currently developing providers: Oracle, DB2, MySQL, PostgreSQL, VistaDB, SQLite, Sybase, Informix, etc. The Entity Data Model primarily of three main concepts: Entities, which represent your domain objects. Associations, which represent a relationship between two entities. Functions, which represent stored procedures or UDFs in your database that can be mapped to model-level functionality. Because there will be plenty of situations where you’ll need to use stored procedures, the Entity Data Model allows you to map functions in your model to a store procedure in your database. This is useful because you can leverage a stored procedure without having to write ADO.NET code to call it, you can simply call a function on your model. EDM functions are represented as methods on your ObjectContext class.
- #7 Estimated Time: 3 minutesTalking Points: This diagram helps to illustrate how each of the Entity Framework’s query options relate to each other. At the core of it all is the database-specific provider. This layer is what translates the query into the SQL flavor required for the underlying data source. Above that is the Entity Client API, which takes the Entity Framework query and passes in down to the database specific provider. If you want to use the Entity Client API directly, you see that you’re only query option is Entity SQL, and because it sits below Object Services, you don’t get any of its benefits. If you want to materialize your queries as objects, and get things like change tracking, identity mapping, relationship loading, etc. then you would use object services, that delegates its queries down to the Entity Client layer. When using Object Services you can leverage both Entity SQL and LINQ to make your queries.
- #8 Estimated Time: 4 minutesTalking Points: The Entity Client is an Entity Framework “port” of the familiar object model of classes used in traditional ADO.NET programming, including:EntityCommandEntityConnectionEntityConnectionStringBuilderEntityDataReaderEntityParameterEntityTransaction Because of this fact it makes it a prime choice for developers migrating to the Entity Framework from ADO.NET. Just like traditional ADO.NET, your queries are returned as sequential text-based data that can iterated over using an EntityDataReader. This is great for performance, but lacks the rich object model that was created as part of your EDM. Entity Client gives you read-only access to your EDM. If data modification is required, you’ll have to use Object Services, which we’ll talk about in a bit. When using Entity Client, your queries are written using Entity SQL, which we’ll talk about in the next slide.
- #9 Estimated Time: 5 minutesTalking Points: While the Entity Client API is great and performant, it lacks the use of our created object model, as well as the ability to update data in our model. The Object Services API sits on top of Entity Client, and provides object materialization on top of our queries. This means that instead of getting text-based results, we get back a collection of CLR objects that we can easily work with. The two mains components of the Object Services taxonomy are: ObjectContext, and ObjectQuery<T>ObjectContext is equivalent to an EntityConnection, and is what manages our connection to the EDM as well as provides crucial services for working with our data.ObjectQuery is equivalent to an EntityCommand and represents a single query executed against our EDM, that is manifested back as strongly-typed objects. Object Services allows you to write queries using two flavors: Entity SQL LINQ To Entities The same Entity SQL queries you would write using Entity Client can be leveraged with Object Services, but with the added benefits you get with the higher abstraction level (i.e. object materialization). While Entity SQL is great for scenarios that require a dynamic query, or greater control over your query’s shape, you’re still working with a string that is error-prone. In addition to Entity SQL, Object Services allows you to write your queries against it in LINQ which provides you with strong-typing, error-checking, and a higher level of abstraction from Entity SQL. If you are already familiar with LINQ, then you don’t have to master Entity SQL in order to query an EDM, because LINQ To Entities will make the translation for you. In addition to object materialization, object services provides you with other benefits/services: Unit of work Your Object Context represents your unit of work, which aggregates all changes made to all entities attached/contained in it, so that when you want to push those changes back to the server, you can do so in a single batch. Identity tracking The ObjectContext keeps track of the entities you’ve queried for by key, so that if you later request the same entity (by key), using the same ObjectContext instance, it will return you the instance it already has instead of re-hitting the database. Eager/explicit loading The Entity Framework doesn’t pre-load any relationship properties for you. If you want to query an entity as well as some of it’s related entities, you’ll need to explicitly request that by performing a “span” using the Include method of the ObjectQuery<T> class. Alternatively you can call the Load method on your entity’s relationship property.
- #11 LINQ has two syntaxesLambda/Method Syntax = customer.Select(...)Comprehension/Query Syntax = from c in customer ...