Using Application Blocks for Data Access
- Using Application Blocks for Data Access
- Using the DAAB
- Retrieving a DataSet
- Using the SqlDataReader to Populate Business Objects
- Complementing the DAAB
A few things trouble and annoy me. One of them, in particular, is all of the custom data access layers in n-tiered software. Why does it bug me so much? Using SELECT, UPDATE, INSERT, DELETE, OUTER JOIN, INNER JOIN and moving data between datasets and fields become dull after a while, and they are error prone. There are more congenial ways to spend one's time, and it's unnecessary to reinvent this piece of code.
If you use .NET and write data-driven applications—which is about 80% of us—go to www.microsoft.com to download the latest copy of the Data Access Application Block, and use that instead. Microsoft effectively pays for a huge chunk of your custom code, which is like a rebate for your project's budget.
The DAAB is implemented in VB.NET and C#—not that language really matters, because .NET is cross language compatible. The only drawback is that the DAAB is implemented for the Microsoft SQL Server Provider rather than being DB-provider agnostic. Such a minor transgression is justifiable, because Microsoft is a public software company that sells SQL Server and gives away the DAAB.
If you are not using SQL Server, I encourage you to treat the DAAB like a design pattern: convert it to using ADO.NET interfaces or the OLEDB provider. ADO.NET supports multiple and custom providers, and modifying the DAAB to use ADO.NET interfaces will still be much quicker than writing your data access layer. If you are not supporting multiple database providers and not using SQL Server, then search and replace SQL provider classes with OLEDB providers; either choice will yield a better result more quickly and reliably than starting from scratch. In this article I will demonstrate how to use the DAAB for SQL Server.
Download and Install the Data Access Application Block
Microsoft has published several application blocks, which they make available with source code at their Web site.
Rather than giving you a specific URL—these things are moved occasionally—I will tell you a good way to find things. Go to google.com and search forDAAB site://www.microsoft.com, all entered into the google search bar. Thesite://moniker limits google to searching a specific site.
The Data Access Application Block .msi file adds the binaries and source code to your PC. All you need to do is add references to the DAAB binaries in your project. Enough said.
Generalize Rather than Customize
If you elect to customize or extend the DAAB, leave the original source and binaries intact and customize through inheritance. Use inheritance or, generalization if you want to add new behaviors. This permits you to upgrade the DAAB in-place and keep the cost of ownership squarely in Microsoft's lap. Contrarily, if you modify the DAAB then you will have to modify and re-test DAAB upgrades.
As mentioned earlier, to use the DAAB for non-SQL Server databases you have to customize the DAAB source code itself. Most of the changes consist of converting provider specific classes (such as SqlConnection) to ADO.NET interfaces (IdbConnection), or using the OLEDB provider classes.