<%@ Page %>
Generic Data Access Application Block for .NET
Introduction
Few months back Microsoft released Data Access Application Block for .NET. The application block is nothing but reusable data access layer for SQL Server. This layer encapsulates most of the frequently used data access tasks such as creating connections, commands and transactions. The block, however, is exclusively for SQL Server. DotNetBips.ApplicationBlocks.Data is developed on the same guidelines but it works with any ADO.NET data providers. This brings generality while programming without scarifying benefits of individual data providers. The original Data Access Application Block can be downloaded from
MSDN Library. I strongly suggest that you go through help documents provided by Microsoft as they explain architecture and functionality of the data block in detail.
Advantages of DotNetBips.ApplicationBlocks.Data
Following are the advantages of using DotNetBips.ApplicationBlocks.Data
- Generic way to access data without scarifying benifits of individual data providers.
- Changes to underlying database can be tackled easily while development is in progress.
- Useful for products that need to support multiple databases.
- Easily configurable via application configuration files.
How DotNetBips.ApplicationBlocks.Data works?
The aim of DotNetBips.ApplicationBlocks.Data is to provide generic data access layer without sacrifying benefits of individual data providers. .NET Data Providers implement a certain set of interfaces. They are:
- IDbConnection
- IDbCommand
- IDataReader
- IDbDataAdapter
- IDbDataParameter
- IDbTransaction
This means that variables of these interface types can hold reference to instances of .NET data provider classes such as SqlConnection and OleDbConnection. Using such 'interface programming' you can create generic data access layer that works with any data provider including providers not available as on date (provided that they implement the same set of interfaces.)
Configuration Settings
As you might have guessed, since DotNetBips.ApplicationBlocks.Data is a generic library we need to configure as per our database. The configuration is achieved via application configuration files (web.config or app.config). The <appSettings> section is used to add some key-value pairs. These keys are retrieved inside the DotNetBips.ApplicationBlocks.Data classes. The configuration section looks as follows:
<appSettings>
<add key="assembly" value="System.Data" />
<add key="connection"
value="System.Data.SqlClient.SqlConnection" />
<add key="command"
value="System.Data.SqlClient.SqlCommand" />
<add key="dataadapter"
value="System.Data.SqlClient.SqlDataAdapter" />
<add key="parameter"
value="System.Data.SqlClient.SqlParameter" />
</appSettings>
Here, you need to specify the assembly that contains the data provider classes. You also need to specify fully qualified names of actual classes used by the data provider.
How to use DotNetBips.ApplicationBlocks.Data
You use DotNetBips.ApplicationBlocks.Data the same way as Microsoft.ApplicationBlocks.Data. Once you put configuration file in place (as shown above) there is nothing different that you need to do in order to use the functionality. Just give reference to DotNetBips.ApplicationBlocks.Data.dll, import the namespace DotNetBips.ApplicationBlocks.Data in your code and start coding!
Known facts and Limitations
There are some known facts and limitation of DotNetBips.ApplicationBlocks.Data. They are:
- Since DotNetBips.ApplicationBlocks.Data is generic functionality of calling stored procedures by passing just parameter values is not available. The original Microsoft code uses SqlCommandBuilder to obtain parameter information at run time. Since CommandBuilders do not implement any interface you can not generalize it.
- Even though DotNetBips.ApplicationBlocks.Data is using individual data providers for best performance, the interface approach may give slight performance hit.
- The working of different data providers for the same task can be different. For example, ExecuteReader for SQL Server might work differently than other databases. In such cases though underlaying methods are the same, you need to take care of such changes.
- DotNetBips.ApplicationBlocks.Data can only be used with data providers that implement interfaces mentioned at the beginning of this article.
- ExecuteXmlReader implementations are not possible as this method is specific to SQL Server.
Download
The ZIP file accompanying this article contains complete source code in VB.NET as well as C# of DotNetBips.ApplicationBlocks.Data component. The download also includes examples in VB.NET and C# that illustrate how to call various methods of the component.
Suggestions & Feedback
Your suggestions and feedback are imortant in order to improve DotNetBips.ApplicationBlocks.Data component. Send them to
webmaster@dotnetbips.com.