Recently I had to type up some documentation on .net data providers and ado.net. I am trying to get feedback on my findings. Please review and provide corrections or opinions.
Summary
This is a high level summary of the basic .Net API’s for interacting with a database. As a developer with mainly a Java and PHP background I was unclear about how ADO.Net related to OleDb and I had no idea what was meant by the term “.Net Data Provider”. I created this because the msdn documentation is HEAVILY focused on ADO.Net and does not give a clear picture of how the many namespaces, interfaces, and classes interact.
.Net Data Provider
- http://msdn.microsoft.com/en-us/library/a6cd7c08(v=VS.71).aspx
- A .NET Framework data provider is
used for connecting to a database,
executing commands, and retrieving
results. Those results are either
processed directly, or placed in an
ADO.NET DataSet. - What that actually means is that a
.Net Data Provider implements the
interfaces defined in the System.Data
namespace. - A .Net Data Provider is similar to a
JDBC driver in Java
System.Data
- http://msdn.microsoft.com/en-us/library/system.data.aspx
This page contains text that makes
you believe that ADO.Net is the CORE
part of .Net data access, however the
reality is that ADO.Net is the
highest level of data access and is
built upon the .Net Data Providers
that implement the interfaces in the
System.Data. - In my opinion it almost seems like
microsoft is trying to hide how
database connections work, so that
users are trapped using controls
provided by visual studio. The
System.Data namesapce contains
Interfaces that need to be defined by
ALL .Net Data Providers
System.Data Core Interfaces
- IDbConnection
- IDbCommand
- IDataAdapter
- IDataReader
Examples of System.Data Implementations
- The following namespaces include classes
that implement the core “.Net Data
Provider” interfaces defined in
System.Data - System.Data.SqlClient
- System.Data.OleDb
- System.Data.Odbc
- IBM.Data.DB2
- ByteFX.Data.MySqlClient
ADO.Net
- http://msdn.microsoft.com/en-us/library/27y4ybxw(v=VS.71).aspx
- ADO.Net is a database query and
manipulation API built on top of the
basic .Net Data Provider classes.
ADO.Net focuses on disconnected,
multi-tier database interaction. - In my opinion the core ADO.Net
classes should be in a separate
namespace like System.Data.ADO just
for the sake of clarity.
ADO.Net Core Classes
- DataSet
- DataTable
- DataColumn
- DataRelation
System.Data is the “package” that contains everything for working with “Data providers” in .NET. It is true that ADO, is one strategy for working with data, but it is the primary strategy in .NET.
ADO is less about specific DB technologies (as it is not necessarily meant to be a database specific technology) and more about data relationships. The terms: Set, Table, Column, Row and Relationship are well understood modeling terms and ADO.NET makes them first class objects in the .NET space.
Data providers provide low-level implementation specific details for supporting the core ADO.NET concepts (tables, rows, etc) and are meant to abstract away the direct implementation details of how to connect to a data provider. For instance, you should be able to, with relatively little effort, swap out a Jet Data provider, with a Oracle Data provider, in terms of DataTables, DataRows, and DataColumns (query details aside) such that your code is minimally impacted by the change. Why is this important? Because it means you can work with non-homogenous data sources with similar command semantics (i.e. you can work with excel spreadsheets and MySql dbs in the same app with the same objects). This makes reuse and repurposing very easy and very straight-forward.
As a general view you can think of the system this way:
Hope that helps.