Entity Client

 

With the next release of the .NET Framework, ADO.NET will introduce a new member of the family of data providers – EntityClient. The mission of EntityClient is to provide a gateway for entity-level queries. Through EntityClient one queries against a conceptual model, not against a specific store implementation of that model. EntityClient does not directly communicate with the data store but it requires a separate, store-specific, provider. EntityClient can work in conjunction with SqlClient that come in the ADO.NET bundle. Additionally, we have launched a partner program to help third-parties produce compatible store providers.

 

EntityClient employs its own language, Entity SQL. An Entity SQL query needs no change in order to work over different store implementations of the same model. That is achieved through EntityClient’s pluggable architecture. Its query pipeline compiles the Entity SQL text to a command tree that is passed to the store provider for native SQL generation. Entity SQL result sets are not restricted to a tabular shape – complex hierarchies may be returned. Even if the store provider doesn’t support them the query pipeline will construct them on the fly because that is the Entity SQL contract. Entity SQL is also highly composable. A sub-query may be used anywhere an expression of that type is accepted.

 

Querying a model directly through EntityClient is suitable for high performance model-based applications. EntityClient does not attempt to materialize objects out of the result set. Instead, it returns a plain DbDataReader for which those applications may implement their own specialized object materialization, or consume the DbDataReader directly.

 

As an ADO.NET provider EntityClient follows the well-known pattern of Connection, Command, Parameter, DataReader, etc. where the class names are prefixed by “Entity”. Of course there are some differences that deserve special attention:

 

Connection String

An entity connection string is inevitably more complex than a store connection string because it must include the latter in its entirety plus additional information about the model and the provider itself, e.g.:

 

“Provider=System.Data.SqlClient; Metadata=../../model | ../../mapping/sql; Provider Connection String=’Server=zlatkom1; Database=NorthwindCTP; Integrated Security=yes;’ ”

 

· Provider - the store provider’s canonical name

· Metadata – a pipe-separated path of folders and individual files where the model and mapping files are stored

· Provider Connection String – a store specific connection string or the underlying store provider

 

EntityConnection can also read a connection string from the app.config file. In that case one can save multiple connection strings with different names in the app.config file and pass the name of the connection string to be used:

 

“Name=Northwind with Integrated Security”

 

Command Text

As it was mentioned earlier, EntityClient uses a new query language – Entity SQL. Just to get a brief sneak at it, here’s an example:

 

SELECT c, c.Products

FROM Northwind.Categories AS c;

 

The above query returns a hierarchical result set that contains all product categories in Northwind and the set of related products for each category. The first thing to notice is it’s very simple. That is because an entity model is shielded from the complexity of database normalization. There is no JOIN between Categories and Products because an entity model has navigable relationships like c.Products that directly return the referred entity or even a collection of entities as in the given example. Lastly, there is no need to project individual columns – Entity SQL can return entire entities instead.

 

A separate blog post, dedicated exclusively to Entity SQL, is coming up soon.

 

INSERT/UPDATE/DELETE

Entity SQL will not support any DML constructs – INSERT, UPDATE, or DELETE in the Orcas release. Data modification could still be done through ObjectContext, or through the native SQL of the target store. It is our goal to implement DML support but for now it’s more important to verify we’ve built the right query language.

 

Feedback Welcome

We strongly encourage user feedback at our dedicated forum: https://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=533&SiteID=1. We believe we’ve designed a great product but we still actively trying to understand customers’ needs so we can make it even better. Additionally, our team is committed to help the developer community adopt the new ADO.NET technology to build model-based applications.

 

 

Zlatko Michailov

Program Manager, ADO.NET

Microsoft Corp.

Comments

• Anonymous
  February 14, 2007
  If you watch the ADO.NET team’s blog then you may have seen the post from today from Zlatko Michailov

• Anonymous
  February 14, 2007
  Another "SQL like, string based language syntax" seems to be a step backwards in the day and age of LINQ and Expression Trees. Wouldn't a set of LINQ providers formulating queries based upon expression trees solved the same problem and fitted better with the whole LINQ Data != Objects story? What is the advantage of the "Command Tree" rather than and the standard "Expression Tree"?

• Anonymous
  February 14, 2007
  This has been bugging me for a while, but I must now admit how disappointed I am that the ADO.Net team...

• Anonymous
  February 14, 2007
  This is a polarizing post- I really want these issues discussed and debated. I'm interested is anyone...

• Anonymous
  February 14, 2007
  "Entity SQL will not support any DML constructs – INSERT, UPDATE, or DELETE in the Orcas release. Data modification could still be done through ObjectContext, or through the native SQL of the target store. " I find this a bit strange. Entities of the Entity framework mapped as C# classes can be updated/deleted etc. using Linq/objectcontext, but not through eSql ? Isn't it so, that the expression tree resulting from the objectcontext actions is what you should use for eSQL statements?

• Anonymous
  February 15, 2007
  The requirements for update from object- and entity-level are quite different. Update from object-level (ObjectContext or LINQ) operates over individual object instances. There is a separate command tree for each instance that is being updated. The assumption is: the number of object instances is relatively small compared to the total number of instances in the store. Entity SQL, on the other hand, operates over entity sets. There should be a single command tree that updates a relatively large set of instances. So object-level update trees are not applicable. Entity-level updates target rather maintenance than application development. By the time maintenance becomes an issue, entity-level updates should be implemented.

• Anonymous
  February 18, 2007
  Data/ADO.NET Orcas Two from the ADO.NET team: Entity Client and Nulls - LINQ to DataSets Part 3 Software

• Anonymous
  March 08, 2007
  According to the ADO.Net Team here and here , there will be no support of DML operations in Entity SQL

• Anonymous
  August 03, 2007
  The comment has been removed

• Anonymous
  June 05, 2008
  With the next release of the .NET Framework, ADO.NET will introduce a new member of the family of data providers – EntityClient . The mission of EntityClient is to provide a gateway for entity-level queries . Through EntityClient one queries against

• Anonymous
  September 10, 2008
  Siguiendo con las pruebas de ADO.NET Entity Framework (ADO.NET EF) comenzadas en este post , en esta

• Anonymous
  December 03, 2008
  Data/ADO.NET Orcas Two from the ADO.NET team: Entity Client and Nulls - LINQ to DataSets Part 3 Software Architecture/SOA/CAB Udi answers, Can or should SOA be implemented without Web Services? David Chappell on The Three Faces of SOA Eric Newcomer: WS-*