A Journey Into the Emotions of Software Developers
Entity Framework Overview
1. Eric Nelson
Developer & Platform Group
Microsoft Ltd
eric.nelson@microsoft.com
http://geekswithblogs.net/IUpdateable
http://twitter.com/ericnel
2. Accessing data in 1990
• ODBC, embedded SQL
Accessing data in 2000
• ADO, Stored Procedures
Accessing data in 2005
• ADO.NET, Datasets, DataReaders
Accessing data in 2010
• ORM baby!
3. What is it?
an Abstraction
technique for working with relational tables as if they
were objects in memory
Intention is to hide away the complexity of the
underlying tables and give a uniform way of working
with data
Why use it?
Developer productivity
Retain database independence
Note:
Using an ORM does not mean you must use the ORM!
4. Many ORMs out there
LLBLGen Pro http://www.llblgen.com/
Nhibernate http://www.hibernate.org/343.html
EntitySpaces http://www.entityspaces.net/Portal/Default.aspx
Open Access http://www.telerik.com/products/orm.aspx
DevForce http://www.ideablade.com/
XPO http://www.devexpress.com/Products/NET/ORM/
Lightspeed
http://www.mindscape.co.nz/products/LightSpeed/default.aspx
Plus many, many more
No clear “winner” = relatively little
adoption of ORM
Developers waiting on Microsoft
Of 31 .NET ORMs in 2003, 9 lasted to 2008
5. Typed Datasets (cough) – shipped
ObjectSpaces “v1” – never shipped
ObjectSpaces “v2” – never shipped
Microsoft Business Framework – never shipped
WinFS – never shipped
LINQ to SQL - shipped November 2007
Visual Studio 2008 & .NET Framework 3.5
LINQ to Entities - shipped August 2008
Visual Studio 2008 SP1 & .NET Framework 3.5 SP1
Note: LINQ to Entities is the most visible part of the
ADO.NET Entity Framework
6. Entity Framework and LINQ to Entities is our strategic
technology
Entity Framework v2 in VS2010 and .NET Framework 4.0
Best of LINQ to SQL moves into LINQ to Entities
Microsoft is using it
Data Services - shipping
Reporting Services
Microsoft “M”
Partners supporting it
Database Vendors – IBM,OpenLink, Data Direct, Devart etc
ORM vendors supporting it
DevForce now target Entity Framework, replacing their own
LLBLGen v3 will target Entity Framework as well as their own
It is not just about ORM
7. What is LINQ?
LINQ is not about databases, it is about objects
LINQ = Language-Integrated Query
Extensions to programming languages to query objects in memory
Why use it?
Productivity!!! LINQ rocks
www.linqpad.net
We ship
LINQ to Objects
LINQ to XML
LINQ to Datasets
LINQ to SQL – just SQL Server
LINQ to Entities – added in .NET Framework 3.5 SP1
Others make LINQ to Flickr etc
9. LINQ to SQL LINQ to Entities
Database Support SQL Server SQL Server, DB2,
Oracle, Sybase,
MySQL ...
Object Relational Simple Complex
Mapping
Capabilities
Not strategic
Status Strategic
Often
Annoying Rarely
10. Entity Framework is not just about ORM
Entity Framework v1 is being adopted
Typically on applications expected to “live” a
long time
Entity Framework is only .NET 3.5 SP1 and
above
Entity Framework is probably not the best
choice for a “short lived” SQL Server
applications
Entity Framework v1 has “warts”
Designer
It is annoying – buggy, clunky
Exposes subset of the functionality
Does not support model first
N-tier story
Stored Procedure Support
Foreign Keys
PoCo
Guids
SQL 2008 New Types
11. “EF is still cutting
development time
“the entity framework
in half. Ya gotta
can kiss my damn
love it.”
ass - this shit is
ridiculous”
12.
13. What is it?
Tools and services to create an Entity Data Model
EDM gives ORM to SQL Server, Oracle, DB2 etc
Tools and services for consuming an Entity Data
Model
Why use it?
Productivity
Complex mapping between entities and database
tables
Works great with ADO.NET Data Services
Notes
Strategic but just released...
14. Entity Data Model
Application model
Mapped to a persistence
store
Conceptual
Comprised of three
layers:
Conceptual (CSDL)
Mapping (MSL) Mapping
Storage (SSDL)
Database agnostic
Comprised of:
Storage
Entities
Associations
Functions
18. Queries materialized as Objects
ObjectContext
ObjectQuery<T>
Built on top of Entity Client
Two query options:
Entity SQL
LINQ
Runtime services:
Unit of work
Identity tracking
Eager/explicit loading
20. ORM is an abstraction layer about data
• Productivity
• Database Independence
Microsoft has two ORMs
• LINQ to SQL – only SQL Server
• Entity Framework (includes LINQ to Entities) – many RDBMS, strategic
ADO.NET Entity Framework includes all the other bits
• EDM, Linq to Entities, ESQL, Object Services
• Part of .NET Framework 3.5 SP1
Entity Data Model – mapping from conceptual to store
• CSDL = Conceptual Schema Definition Language
• SSDL = Store Schema Definition Language
• MSDL = Mapping Schema Definition Language
Two query languages
• ESQL = Entity SQL. Read only query language similar to SQL
• LINQ to Entities = Language Integrated Query to the EDM
21. • .NET Framework 4.0
Entity Framework v2 • http://blogs.msdn.com/efdesign
Entity Framework • Across MS Products and Technologies
more widely adopted • Reporting Services vNext
• Better ORM capabilities in LINQ to Entities
Rough edges
• POCO support, N-Tier, Model First
removed
Technologies work • e.g. ASP.NET Dynamic Data and Entity
Framework
better together
• Less xml editing during development
Better tooling
22. 1990 to • Data Access technology remained
reasonably static
2007 - • Procedural, API access
• Surfaced the database schema
Tables • No clear ORM choice
• LINQ – excellent addition to the .NET
2008 – languages
• Entity Framework and the EDM – strategic
Objects investment
• Productivity leap
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.
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.
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.
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.
LINQ has two syntaxesLambda/Method Syntax = customer.Select(...)Comprehension/Query Syntax = from c in customer ...