Complementing the DAAB
Good, speedy complements to the DAAB include the SqlCommandBuilder class and the XML Schema Designer.
The SqlCommandBuilder can generate CRUD (create, read, update, and delete) methods for you if you provide it with a SELECT statement. From the SELECT statement the schema can be read and the other commands can be generated.
The XML Schema Designer (also, referred to as XSD) is similar to an ERD (entity relationship diagram) tool. The XML Schema Designer enables you to drag and drop tables from the Server Explorer onto a Schema Designer page—add an .xsd item to your project—and to describe relationships. The schema designer generates strongly typed DataSets and DataTables automatically and perfectly every time.
Because the strongly typed DataSets and DataTables use named properties, they are easier to program against. Because the strongly typed DataSets and DataTables inherit from DataSet and DataTable, you can use them just as easily with the DAAB as with a plain vanilla DataSet and DataTable.
While we don't have time to cover all of these things here, a good book (like my Visual Basic .NET Power Coding (Addison-Wesley, 2003) or Advanced C# (McGraw-Hill/Osborne, 2003)) can help you master these other techniques.
Writing a Custom Data Access Layer
Even if you do not use SQL Server—which I find very easy to use and well-supported—you can still use the DAAB. Treat the DAAB like a design pattern, and customize it to use another provider, like OLEDB. Using search-and-replace commands, you can completely revise the DAAB, replacing the SqlCommand or SqlDataReader with the OLEDB versions of these classes. Or, better yet, you can go one level higher and convert the OOP data access types to their interface equivalents. This will take some exploration, but it shouldn't be that hard to do.
However, if you are using SQL Server and want to extend the DAAB, then do so through inheritance. This leaves the real DAAB intact, permitting you to replace it with upgraded versions, leaving the cost of ownership with Microsoft. Ultimately, this casts Microsoft in the role of free consultant.
You may enjoy writing data access code and SQL. I do, within reason. However, after about 75 or 100 stored procedures, they start to feel redundant and tedious. Plus, I haven't seen any data access code any better—and a lot that was worse—than the DAAB.
The point of this article is that some real, good code already exists that can dramatically improve the quality and development time of software projects. The application blocks, specifically the DAAB (and EMAB, or Exception Management Application Block) are two such examples. If you are spending weeks and months writing a data access layer, the DAAB can save you lot of time and money.