Programming with ADO.NET Interfaces

.NET supports two flavors of polymorphism: (1) the polymorphism introduced through inheritance, virtual methods, and the virtual methods table, and (2) the polymorphism introduced with COM and interfaces. The first form, called inheritance polymorphism , means that all instances have a common classification. (For example, bears and goats can both be classified as mammals.) The second form of polymorphism, called interface polymorphism , means that all instances have a common capability but are not required to have a common classification. (For example, radios, televisions , hearing aids, telephones, and bullhorns all have the ability to attenuate volume, but they don't necessarily share a common classification.)

ADO.NET (and all of .NET, really) supports both forms of polymorphism. Interestingly, ADO.NET directly supports interface polymorphism by having classes in both kinds of providers ”OleDb and SqlClient ”implement interfaces. For example, both the OleDbCommand and SqlCommand providers implement the IDbCommand interface. As a result, both OleDbCommand and SqlCommand can have different implementations and classifications but can be manipulated by the same control; that is, they can be managed by the same code if the code is written to work with the IDbCommand interface rather than with one provider or the other.

You are not required to write your code to use interfaces; you simply have this option. However, it is important to note that interfaces provide an optimal kind of flexibility. Returning to the IDbCommand interface, if we write code to use IDbCommand to manage SQL or stored procedures, any class that implements IDbCommand will do. The implication then is that any provider will do. Let's draw a logical conclusion here. If you were writing a commercial application and you did not want to force a customer to use a specific database vendor, interfaces would let you write one body of code that allowed the customer to pick the database vendor. As long as that vendor offered database provider classes, or one of the existing providers worked, then customers would be free to pick and choose database vendors . They would not be locked into a particular choice based on your code.

The notion of using interfaces is so powerful that it is one of the patterns (a standard approach for a category of problem) promoted in Design Patterns by Erich Gamma and colleagues [1995]. It is probably no accident that interfaces were used with ADO.NET.

Because the ADO.NET interfaces already exist, all you have to do is use them. Instead of declaring a specific provider class like OleDbConnection , use the interface that a particular class implements. Declare your variables as interface types and create instances of the specific provider type based on some conditional criteria. You will find it amazingly simple to switch database providers if the need arises. A good architect should be able to help you design a database application that supports switching providers without changing or recompiling your code at all.

For a complete list of ADO.NET interfaces, refer to the Interfaces section of the System.Data Namespace help topic in Gamma et al. [1995].