Writing an EF Enabled ADO.NET Provider
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.
What is an Entity Framework Enabled ADO.NET Provider?
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.
Why write Your Own Provider?
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.
Writing Your Own EF Provider
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.
Pre-Requirements
ADO.NET Provider
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.
Major Provider Components
The major functional components of a provider are the following:
ProviderFactory
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.
ProvidersServices
ProviderServices sets up the manifest, creates database connections, and triggers the SQL generation for both query and update pipelines.
Command and Connection
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.
Provider Manifest
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.
Query Pipeline
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.
Update Pipeline
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.
SQL Generation
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.
Conclusion
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.
Related Articles
· 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