Some ADO.NET classes supports built-in asynchronous query behavior. Some aren’t. In this post, we’ll revise the former classes, like SqlDataReader. However, if you are familiar with multithread computing (particularly, in the .NET Framework) you can easily implement asynchronous execution in classes which don’t support it, such as the TableAdapter.
Before you’d do anything, you should introduce a new name-value pair into your connection string: Async=true or Asynchronous Processing=true. Including it, you enable asynchronous queries to be executed on the database server. This was the easy part.
Writing your asynchronous data access class is a little bit more complicated. If you are familiar with delegates and the classes of System.Threading, then you are ready to go. But if you’d like to rely on built-in logic, consider using the DbCommand’s BeginExecuteReader and EndExecuteReader. First the code, then the explanation:
I have another post about this topic, you can find it under the title of Create a Vendor-Independent Data Access Class. But let’s be clearer: the System.Data.Common namespace provides a set of interfaces and classes to build your provider-agnostic data access class. Using these classes, you can even build new data providers.
The .NET Framework comes with four providers installed and configured in Machine.config. These are OdbcProvider, OledbProvider, SqlClientProvider and OracleClientProvider. When you want to connect to a data source, you must at least know its type name, and have a valid connection string. Without these, you’re stuck. The good news is that you can store both of these in the same place: yes, in a .config file, in the connectionStrings section. An example:
<add name=”myString” connectionString=”Data Source=.SQLEXPRESS; Initial Catalog=Northwind; Integrated Security=true;” provider=”System.Data.SqlClient” />
Then you should instantiate a DbProviderFactory object, generate a DbConnection with it, and open the connection through that. The code is the following:
Vendor independent or provider agnostic data access is a relatively easy thing to implement, thanks to the structure of ADO.NET. You’ll find the classes you’d need in the System.Data.Common namespace.
To access data without knowing the provider type, you’d start in your web.config, by adding these entries to it:
<add name=”theString” connectionString=”your string here” providerName=”System.Data.SqlClient”/>
<add key=”select” value=”SELECT * FROM Customers”/>
Then in your data access class, you should define a DBProviderFactory, create an instance of it by calling the GetFactory static method passing the provider type as parameter (defined in your web.config). Then you should create a DBConnection class and a DBCommand class, or anything else you’d need, and use it as if you’d use for example the SQL classes. Example:
This objective means that you can use the classes that can be found in the System.Collections.Specialized namespace. Unfortunately, there are a bunch of classes that you’ll never use in a live environment (remember the magic keyword: Generics), but you’ll have to know them for the exam.
We’ll deal with the following classes in this post:
Before taking any step forward, please note that the collection classes presented here are obsolete. This is because they have generic counterparts, with which we’ll deal later. For the exam, you should know these classes, but in the real life, use generics instead.
First let’s see the interfaces which will be useful when defining our custom collection classes: IEnumerator and IEnumerable. These interfaces are the only way to iterate over your data in a foreach loop. You decorate your class (or struct) with the IEnumerable interface, which has a method named GetEnumerator, of type IEnumerator. Note that you can use a foreach loop without implementing IEnumerable. Simply create a method in your class with the name of GetEnumerator, and the type of IEnumerator. Then you can make use of the yield keyword, which returns data, and stores the position of the index. Syntax:
In yesterday’s posts, we examined how to retrieve and process data from a database with the help of ADO.NET. Today, we take a look at the third major area of ADO.NET: XML.
I assume that everybody got this far already met with XML, some may also become quite fond of it (shame on me, but I haven’t), so I wouldn’t waste time to introduce it. Instead let’s get see what ADO.NET has for us. In this post, I will revise the following:
- Processing stream-based XML
- Processing in-memory XML
- XML data binding
- XML and DataSet integration
I’ll not going to describe LINQ to XML, since it isn’t covered in the exam, and even when you work with LINQ to XML, you’ll still need to know the basics of ADO.NET to perform for example basic XML data binding.
In the previous post, we discovered the connected layer of ADO.NET, namely the Command, Connection, DataReader classes. In this post, I’d like to review the disconnected layer of ADO.NET. The main classes are the DataSet and the various DataAdapter classes in this layer. But when should we use this one?
As noted previously, database connections are probably the most expensive resources in a given application. Therefore, it’s a good idea to use a limited number of queries for retrieving large pieces of data, than use numerous queries for little amount of data. The disconnected layer is built upon this theory. Large pieces of data (in fact, even a whole database) can be pulled to the client, then processed without the requirement of an open connection to the database. When the processing of data is completed on the client, it can send back the changes committed, and the database can be updated with these changes. Now let’s see the class that provides all of these features: