ADO.NET – The Disconnected Layer

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:
Continue reading “ADO.NET – The Disconnected Layer”

ADO.NET – The Connected Layer

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:

Continue reading “ADO.NET – The Connected Layer”

Implement a DataSource Control

Implement a DataSource control

We’ll look into the details of the following DataSource controls:

  • AccessDataSource
  • LinqDataSource
  • ObjectDataSource
  • SqlDataSource
  • XmlDataSource

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:

Continue reading “Implement a DataSource Control”

Create and Register Client Script

There are three ways of defining a client script on an ASP.NET Web page:

  • Define a script block on your page
  • Use the ClientScriptManager class to dynamically add JavaScript at run time
  • Use the ScriptManager server control to register JavaScript

Now let’s look deeper into the details. The first method of defining scripts is the traditional method. It has nothing to do with ASP.NET, so you can embed your scripts like this into simple HTML pages or PHP as well. You should add a script tag anywhere on your page (the head section is the most preferred) and define your JavaScript there, like this:

<script type=”text/javascript”>

    function myFunc() {

        //do something

    }

</script>

Continue reading “Create and Register Client Script”

Implement Web Forms by using ASP.NET AJAX

Using ASP.NET AJAX provides the following benefits:

  • Improved efficiency, since a massive amount of processing occurs in the browser
  • Familiar UI elements
  • Partial-page rendering
  • Client integration of ASP.NET services, such as authentication, roles, profiles
  • Auto-generated proxy classes for web services called from client script
  • Extendible controls with client functionality
  • Browser compatibility

 
Continue reading “Implement Web Forms by using ASP.NET AJAX”

Calling Web Services from Client Script

Web services can be called from client scripts, such as Javascript too. This is most useful for example if you need to expose a database result set to your javascipt client code. Both XML Web services and WCF services can be called from client script. The steps are essentially the same for both scenarios.

First you must expose your service to be consumable from client script. For a standard XML Web service, add the ScriptServiceAttribute to your .asmx.cs file. If you work from template, you just need to uncomment the line. Your result would look like this:

ScriptService1

To set up a WCF service, you should ensure of the following:

  1. The service must be hosted by a web application within a .svc file. You will need to point to this file later.
  2. You must configure the web application to support service calls from client script.

Continue reading “Calling Web Services from Client Script”

Call a WCF Service

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:

  1. Define the service contract
  2. Implement (or write) the contract
  3. Configure the endpoint(s)
  4. Host the service in an application
  5. 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.

Continue reading “Call a WCF Service”