ASP.Net (the website) has a series of tutorials on building a three-tiered data architecture using ASP.Net 2.0 (view the tutorial here).

And for the most part, it is a good series. The only thing that I kind of disagree with is their decision to use typed DataSets as the data access layer.

While sure, that creates a form of data independence, as you're not building SQL strings through out your code, it still doesn't feel like a data access layer.

Personally, on sites that I may need to switch the back end database for, I create an interface, which performs all the tasks I need, plus a few extras, such as RunStoredProcedure, RunNonQuery, RunQuery, and GetDataSet.

Since there is an interface for all DataReaders, I return that from my interface - giving me the ability to be database agnostic.

The code class that I use for manipulating the database I will place in a separate DLL, and then use reflection to instantiate that object in the Global.Application_Startup event handler. Making my data access layer, a global object (where I've long stashed other global variables which are stored in the Web.Config file).

So My project solution will look like this:

• Web Project
• Database Interface
• SQL Server Data Accessor
• Oracle Data Accessor
• MySQL Data Accessor

Sure, there is a slight performance hit on using reflection and late-binding the data access layer, but that is a trade off I willingly took for my code to be database agnostic.