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