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:
The data component of the .NET Framework (namely ADO.NET) works with two layers. These layers are called the connected and the disconnected layer. As you can guess, their names refers to the fact whether they are actually connected to a data source.
But before we dig into their details, let’s see what do they have in common – the fundamentals of ADO.NET.
To connect to a data source, your very first step will be to chose a provider. There are four providers built in the .NET Framework 3.5, these are the OleDbProvider, the OdbcProvider, the SqlProvider and the OracleProvider. You typically set the provider in the connectionString section of the web.config. Each provider declares four classes to manipulate data, these are:
- Command: represents a database command (stored procedure or ad hoc).
- Connection: represents a database connection. You typically refer to the web.config connectionStrings section to retrieve one.
- DataReader: provides a read-only, forward-only way to get data from a database.
- DataAdapter: lets you fill data objects of the disconnected layer, and write back the changes to the database.
Each of these classes gets the prefix of the provider name. So for example, when you want to connect to a SQL database, you will use a SqlConnection class to do so. Let’s take a closer look to these classes:
Implement a DataSource control
We’ll look into the details of the following DataSource controls:
These controls lets you easily bind data to your data-bound controls. You can query, update, delete data sources declaratively with the data source controls. Now let’s take a closer look to these controls:
Setting up WCF Services and consuming them is a little more difficult than the ASP.NET Web Services. Essentially, there are five steps to take, namely:
- Define the service contract
- Implement (or write) the contract
- Configure the endpoint(s)
- Host the service in an application
- Reference and call the service from a client
We will go through these steps every time we create a WCF Service. In my example, I will follow the MSDN tutorial (which does the same process in six steps). I’ll create a console application as a host for the service, and will consume it from ASP.NET. Let’s begin! And please note, if something isn’t explained enough, feel free to change to the MSDN tutorial.
Web services provide a way to connect systems with little connectivity.
There are two types of services which you can consume in your web applications:
- ASP.NET Web Services are bound to IIS and ASP.NET
- WCF Services haven’t got these limitations
We will cover both of them. Let’s start with the former!
ASP.NET Web Service (aka .asmx files) are simple wrapper classes around standard SOAP services. They let you focus on what you want to expose instead of the hows and whys. To create one, you should write a class that inherits from System.Web.Services.WebService, or simply click add new item, then select the Web Service file. This will generate the following output:
There will come the time in every web application’s lifetime when it needs to display data. That data will be displayed in ASP.NET controls, but first they need to be bound to that control correctly. In this post we will consider the ways to do so.
There are two types of data-binding: Single-Value Binding and Repeated-Value Binding. Consider the former first.
To bind data to an ASP.NET control which supports it, you use the <%# %> delimiters in the property you want to bind to the data. This happens in the .aspx page, not in the code-behind. Between these delimiters, only valid data binding syntax can occur, for example:
protected string GetUserName()
<asp:TextBox runat=”server” Text=’<%#GetUserName()%>’/>