11. Object Relational Mapping Technique for working with relational tables as if they were objects in memory Hide away the complexity of the underlying tables and give a uniform way of working with data
13. Many attempts Typed Datasets Objectspaces ‘v1’ Objectspaces ‘v2’ Microsoft Business Framework WinFS Linq to SQL NHibernate Will “RIP” Not Microsoft’s
14. ADO.NET Entity Framework Microsoft’s strategic technology Used in other Microsoft technologies (reporting services) V2 released with .NET 4.0 14
15. Entity Data Model Invented in the 1970s, by Dr. Peter Chen ERM Conceptual Layer Mapping Layer Storage Layer Now: EDM in ADO.NET Entity Framework
20. Eager Loading Structure the initial query in such a way that all of the required objects are returned in the initial query from c in nw.Customers.Include("Orders")select c;
22. Lazy Loading Related objects are loaded automatically for you when you access them
23. POCO Support Plain Old CLR Object User your own POCO objects with no EF attributes Code your POCO classes Code Entity Framework Context Or use T4 POCO entity generator by VS2010
24. Questions on POCO Do I still need an EDM? Yes How is metadata mapped to POCO entities? Convention based mapping Entity Type, Property, and Complex Types names must match those defined by in EDM Is deferred/lazy loading supported? Yes
25. Lazy Loading on POCO Declare lazy-loaded property as virtual Make sure to enable ContextOptions.LazyLoadingEnabled What’s under the hood?
29. Performance & security? Connections to database vs. amount of data You can work with stored procedures You can work with views You can define how the ADO.NET Entity Framework loads your data to Eager Lazy (Explicit)
31. A WCF Service Proxy Data Binding Entity Framework ObjectContext available ObjectContext not available Distributed system – WCF service SQL Server 2008
32. JSON/ XML HTTP/REST WCF Data Service DataServiceContext Data Binding HTTP/REST Entity Framework ObjectContext available ObjectContext not available Distributed system – WCF Data service SQL Server 2008
34. Entity enhancements Foreign-keys supported in the conceptual model Testability enhancements IObjectSet<T> and ObjectSet<T> Easier to mock data context and data entities for tests Lazy loading for related objects Options now for explicit or implicit loading
35. Support for persistence ignorant objects Persistence ignorant objects POCO objects with no EF attributes, etc. Mapped to conceptual model via convention Change tracking possible with generated proxies or snapshot Managing types in n-tier applications Easier to add/attach objects to a context More control over object state Issues you should consider You still need the Entity Data Model (edmx) To use objects with WCF – use ProxyDataContractResolver
36. Designer enhancements Support for complex types Singularization& pluralization Model first development Creates DDL for database based on your model Designer extensibility Influence the EDMX generation Add visuals Influence DDL creation
37. Code generation customization Based on T4 templates Included as of VS 2008 Runtime support, but not much design support T4 and Entity Framework T4 used to generate code from model Create new T4 templates to use instead Add validation logic Create POCO objects
38. References ADO.NET team blog – keep up with new features in Entity framework http://blogs.msdn.com/adonet ADO.NET C# POCO Entity Generator ADO.NET C# Web Site POCO Entity Generator WCF Data Services team blog http://blogs.msdn.com/astoriateam
Dr. Edgar F. CoddE. F. Codd (Edgar F. "Ted" Codd) formed the concepts for organizing and accessing data that are embodied in the relational database, the predominant approach to data organization in today's business world. Critical of IBM's then current data management systems, Codd, as a young IBM programmer working in IBM's San Jose Research Lab in California in 1970, proposed that data be organized according to principles based on identified relations between various kinds of data. The data itself would be organized in two-dimensional (row and column) tables and specific items in a table could be related to data located in other tables. Codd saw the need to reduce or eliminate redundancy in data and to allow data to be accessed through logical rather than physical identification. One of Codd's key ideas was the process for organizing data into the appropriate number of tables, a process known asnormalization.
- No separation between code and database schema. You still see a lot of SQL statements.- You also create dependency with specific database schema- SAP ERP database contains more than 30,000 tables.
Maintainabity, security, efficiency andscalability let a DBA decideto:Splitdata of oneentityintoseveraltablesPutting data forseveral types of entitiesintosametableSupply projectionsthatlooseentity concepts thatmight have been present in tablestructures
Typed Datasets – shippedObjectspaces ‘v1’ – never shippedObjectspaces ‘v2’ – never shippedMicrosoft Business Framework – never shippedWinFS – never shippedLinq to SQL – shipped, won’t be discontinuedLinq to Entities – shippedEntity Framework- shipped
Entity Framework- shipped
ERM = Entity-Relationship ModelEDM = Entity Data Model
Explain the inner workings of the entity framework Three types of commands: LINQ to Entities against Object Services Materialization to Conceptual model classes or anonymous classes if projected Entity Sqlagaints Object Services Materialization if no projection + streamed data on row level Call model defines functions or specific Entity SQL functions. Entity Sql against Entity Client No materialization + streamed data on column levelExplain the path of commands…
Do I need an Entity Data Model before I can use POCO?Yes – POCO support in Entity Framework 4.0 simply removes the need of having persistence specific concerns in your entity classes. There is still the need for you to have a CSDL/SSDL/MSL (collectively EDMX) metadata so that the Entity Framework is able to use your entities along with the metadata in order to enable data access. There is a separate effort that we are working on that will allow you to do true “code-first” development without the need to have a predefined EDMX model. A community preview of this feature will be released to the web in the coming months. We will roll this into the product the first chance we get. As always, your feedback will be helpful.How is metadata mapped when using POCO entities?In Entity Framework 3.5, both EntityObject and IPOCO based entities relied on the use of mapping attributes that were meant for decorating and mapping the entity types and properties back to the corresponding elements in the Conceptual model. Entity Framework 4.0 introduces convention based mapping for allowing mapping of Entity Types, Properties, Complex Types and Relationships back to the conceptual model without the need for explicit decoration. The simple rule here is that Entity Type names, Property names and Complex Types names used in your POCO classes must match those defined by the conceptual model. Namespace names are ignored and don’t have to match between the class definition and the conceptual model.Is Deferred (Lazy) Loading supported with POCO?Yes – Deferred (Lazy) loading is supported with POCO through the use of proxy types that are used to provide automatic lazy loading behavior on top of your POCO classes. This is something that we’ll cover when we get to deferred loading – until then know that eager loading via the use of “Include” is also supported, like so:
The virtual keyword is used to modify a method or property declaration, in which case the method or the property is called a virtual member. The implementation of a virtual member can be changed by an overriding member in a derived class. When a virtual method is invoked, the run-time type of the object is checked for an overriding member. The overriding member in the most derived class is called, which might be the original member, if no derived class has overridden the member.What’s going on under the covers?The reason why this works is because when I marked my collection property as virtual, this allowed the Entity Framework to provide a proxy instance for my POCO type at runtime, and it is this proxy that does automatic deferred loading. The proxy instance is based on a type that derives from my own POCO entity class - so all functionality you have provided is preserved. From a developer point of view, this allows you to write persistence ignorant code even when deferred loading might be a requirement.Manual instantiation of Proxy instances for POCO entitiesIn order to enable creation of proxy instances for adding/attaching, you can use the CreateObject factory method on ObjectContext for creating entity instances:Category category = context.CreateObject<Category>();
Snapshot based change tracking is what you get with pure POCO entities that don’t use proxies to handle change tracking. This is a simple change tracking solution that relies on complete snapshots of before and after values being maintained by the Entity Framework. These values are compared during SaveChanges to determine what has truly changed from their original values. In this model, unless you are using Lazy loading (must use virtual keyword), the runtime type of your entities is the same as you define for your POCO entities.Problem:Entity Framework’s Object State manager will go out of sync with your own object graph, before SaveChanges called. That’s because of no direct notification of changes to EF anytime your objects changeThecomparison during SaveChangesis relatively expensive when compared to the way change tracking works with EntityObject (non POCO) based entities.Proxy based Change Tracking is a different solution if you care about very efficient and up to date change tracking as you make changes to your entity values, relationships and object graph.You can leverage proxy based change tracking for a particular entity type if you declare all mapped properties on that entity type as virtual.Change Tracking proxies subclass your POCO entity class to provide you with this capability during runtime without requiring you to implement the IPOCO interfaces yourself.How?Your class must be public, non-abstract or non-sealed. Your class must also implement public virtual getters/setters for all properties that are persisted/mapped. Finally, you must declare collection based relationship navigation properties as ICollection<T> only. They cannot be a concrete implementation or another interface that derives from ICollection<T> (a difference from the Deferred Loading proxy)