The official source of information on Managed Providers, DataSet & Entity Framework from Microsoft
The information in this post is out of date.
Visit msdn.com/data/ef for the latest information on current and past releases of EF.
Part 1: Provider Overview
This article is the first in a series designed to teach developers the basic steps to write an Entity Framework Enabled ADO.NET provider. This article will give you an overall idea of what a provider is, why you should write one, and how the major pieces in the provider work with one another. Future articles will explain each piece in more detail. After reading all the articles, you will have the knowledge necessary to write a simple provider for EF in SQL which supports strings, integers, and Booleans. Note that the last article will contain the entire sample provider written through the series.
An EF enabled ADO.NET provider –which I’ll also refer to as EF Provider—resides between the Entity Framework and the database backend. The role of the provider is twofold: first, it creates a series of mappings between the native database types and the EDM types that the developer will write their code against; second, it instantiates the query and update pipelines used to generate read and update queries against the database.
Entity Framework already offers an EF Provider optimized to work with SQL Server 2008 and above. Why write your own then? You should consider writing an EF provider if you have your own ADO.NET provider and would like to add first-class Entity Framework support.
The easiest way to write an EF provider is to start from an existing one. The Entity Framework team created the Sample EF Provider for SQL Server which offers DDL Generation in addition to basic CRUD. The provider outlined in this series of posts is a simplified version of the Sample EF Provider. The outcome will be a provider with support for Query and Update on integers, strings, and Booleans. Hopefully this will make it easier to understand how an EF provider works, and subsequently easier to implement your own.
Our provider will extend the basic ADO.NET SQLClient provider for SQL Server. The ADO.NET provider must support the underlying database. If you would like to write an EF provider for a different database, be sure to read this page for a list of third party ADO.NET providers.
The major functional components of a provider are the following:
The provider factory is where it all begins. It spawns up ProviderServices and gives access to commands and connections. Please read below for more overall information. We will discuss how to implement the provider factory in a future article.
ProviderServices sets up the manifest, creates database connections, and triggers the SQL generation for both query and update pipelines.
These two classes are thin wrappers over the DBCommand and DBConnection classes in System.Data. Command represents the SQL statement to be executed and Connection stores the DB connection info.
As stated above, the manifest creates the mapping between database and EDM types. It may also contain mappings for SQL functions. Since we are only providing support for three types, our manifest will be very simple. We will provide in-depth look at writing a Provider Manifest in a future article.
The query pipeline translates ESQL and LINQ queries into SQL statements that get executed against the database.
Entity Framework takes in an ESQL or LINQ query and transforms it into an Expression Tree. The query pipeline creates a command, which invokes the SQL Generation module to create the final T-SQL query. We will outline how to implement a query pipeline in a future article.
The update pipeline translates update expressions into CREATE, UPDATE, or DELETE statements that get executed against the database.
The Object State Manager in Entity Framework invokes the Update Pipeline, passing down a command tree and the manifest as arguments. This command tree describes a set of create/update/delete operations to complete. The pipeline generates a DML executes it using a DBCommand. We will provide in-depth look at writing an Update Pipeline in a future article.
The SQL Generation module takes a command tree and generates valid T-SQL based on the expression. We will reuse the SQL Generation code from the Entity Framework Sample provider since it our basic needs. We encourage you reuse the SQL Generation component if you are writing an EF provider for SQL. Please see this document to learn more about SQL Generation.
In this article, we outlined the role of an EF provider within the EF stack, as well its inner workings. This series will feature in-depth articles for the major components of an EF provider. We would love your feedback, so please let us know if you have found this helpful.
· Part 2: Writing the Provider Manifest
· Part 3: Query Pipeline, ProviderServices, ProviderFactory (Coming soon)
· Part 4: Writing the Update Pipeline, and Sample Code (Coming soon)
Thank you Pedro Ardila Entity Framework PM