अजपा योग आणि शांभवी मुद्रा ध्यान : श्वास, मंत्र, मुद्रा आणि ध्यान यांच्या सहाय्याने मनःशांती, एकाग्रता, चक्र संतुलन आणि कुंडलिनी जागृती. अधिक माहिती आणि आगामी तारखांसाठी येथे जा.

<%@ Page %>

Generic Data Access Application Block for .NET


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:
	<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" />
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.


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.

Bipin Joshi is an independent software consultant and trainer by profession specializing in Microsoft web development technologies. Having embraced the Yoga way of life he is also a meditation teacher and spiritual guide to his students. He is a prolific author and writes regularly about software development and yoga on his websites. He is programming, meditating, writing, and teaching for over 27 years. To know more about his ASP.NET online courses go here. More details about his Ajapa Japa and Shambhavi Mudra online course are available here.