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: http://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.