MSDN Magazine - July 2008 - (Page 72)

tion properties on each Entity Type that is a party to the relationship. Relationships themselves are first-class citizens within the EDM and are explicitly defined as Associations within the EDM: The current EDM grammar is defined in an XML Schema Definition Language (XSD) that ships with the product. It is not expected, however, that most people will develop the XML by hand, but rather will use the tools provided in Visual Studio. That said, the team has heard of interest in Domain-Specific Languages (DSLs) and in alternative persistence mechanisms (databases being the common one) for EDM models, and it is evaluating the options for expansion in upcoming releases. Who Needs Another New Query Language? So in short, why did we create a new data modeling technology in the first place? Although a number of data modeling technologies or languages existed prior to the EDM, none were able to satisfy the primary goals Microsoft was trying to accomplish, and none served to make the much-used Entity Relationship model executable. The team investigated numerous existing data modeling technologies but, realizing that all were fairly specific or focused to certain problem areas, began developing the EDM to create a model that met these goals and could truly be used as a core data model across a suite of developer and server technologies. Why Describe the EDM with XML? After much consideration, XML was chosen as the first serial representation for the EDM. Having a well-defined XML format enables developers and third parties to do transformations into this format and to load into the Entity Framework’s metadata runtime, either through generating XML files (or resources) or by loading from dynamically generated XML representations. It is conceivable, however, that other representations of the EDM could be created, and it is likely that alternate representations will be seen as the product moves forward with future releases. The last question concerning the development of the EDM is why create a new query language? Why not use an existing one? The answer will become clearer as I dig slightly deeper into the EDM. So far I’ve talked about why the EDM was created and the various constructs used in the EDM, as well as the fact that the model is descendant from the Entity Relationship model. In creating a model that was not only able to map cleanly to the underlying data store but also represent the application-level domain model developers would like to program against, the EDM needed to be capable of modeling concepts such as inheritance and polymorphism. Since current relational query languages do not support querying based on inheritance, relationship navigation, or the return of polymorphic results, a new query language was needed to satisfy this requirement. Thus was born Entity SQL (ESQL), a new SQL dialect that adds the ability to query based on the concepts that are not supported in previous SQL dialects. ESQL extends the existing SQL language in much the same way as the EDM extends the Relational model used in databases. Additionally, ESQL is also not tied to the syntax of any specific back-end database, allowing the queries (and/or the application) to be written once, regardless of the back-end database being targeted. In the following example, I look at a simple ESQL query that will retrieve all blogs with at least one blog post and the associated Person (or in the case of my model, the blog owner): ADO.NET Entity Framework select c, c.Person from travelEntitiesGeneral.Blogs as c where c.BlogPosts.Count > 0 Metadata Workspace Entity SQL “SELECT Value Customer FROM ” LINQ IEnumerable Object Services ObjectContext ObjectQuery Data Classes DataReader EntityConnection EntityCommand ExecuteReader Object Metadata (O-Space) Entity SQL O-C Map Conceptual Schema (C-Space) C-S Map Store Schema (S-Space) “SELECT VALUE Customer FROM ” Implementing the EDM CCT CSDL Client View Engine EntityClient Data Provider Native SQL “SELECT ID, CompanyName, FROM ” MSL CCT DataReader SQLConnection SQLCommand ExecuteReader SSDL ADO.NET Data Providers ADO.NET 2.0 Figure 4 ADO.NET Entity Framework Architecture 72 msdn magazine The ADO.NET Entity Framework is an evolution of ADO.NET and the first concrete implementation of the EDM, providing a higher level of abstraction when developing against a relational database. In version 1.0, the team has been focused on building up the foundation of a platform, more than just a simple ORM, which will allow developers to work against a conceptual or object model with a very flexible mapping and the ability to accommodate a high degree of divergence from the underlying store. Entity Framework

Table of Contents Feed for the Digital Edition of MSDN Magazine - July 2008

MSDN Magazine - July 2008 Contents Toolbox CLR Inside Out Flex Your Data Data Points Advanced Basics Office Space Cutting Edge Data Services ADO.NET Data and WPF Transactions WCF P2P Test Run Security Briefs Foundations .NET Matters {End Bracket}

MSDN Magazine - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.