oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Learning ASP.NET for the ASP Developer, Part 1

by Neel Mehta

The combination of the .com boom of the '90s and the success of Microsoft's ASP technologies created a huge number of ASP programmers. The weaknesses of ASP are now well known, and the ability to translate ASP knowledge into a new platform is often the desire of many of these ASP programmers. This is the goal of this article.

This article is presented in three parts. In this first part, we give an introduction to ASP.NET and provide a motivation for the framework. In the second part, we will delve deeper into ASP.NET, showing how the basic concepts in part one can be extended. Finally, in the third part, we will illustrate how you can scale up to larger web sites by sharing code across multiple pages of a site (similar to the server-side includes of classic ASP). We will also demonstrate how coding in ASP.NET can make a cumbersome task in classic ASP relatively straightforward.

This article will show how you can leverage your knowledge of classic ASP to master ASP.NET. Our goal of this article is to cover the major aspects of building large-scale ASP.NET web sites without overwhelming you with a steep learning curve. The aim is to get you to think like an ASP.NET developer. As a result, you will be able rapidly tap into the power of the ASP.NET framework. Furthermore, coding in ASP.NET will offer you several opportunities to dramatically simplify your program logic.

(Our intent is not to show you how you can take ASP code and, line by line, convert it to work in the .NET framework. Since ASP.NET is backward-compatible with classic ASP, there is not much to do if you are copying your code to a server running ASP.NET. So even though you may end up having to revamp your web site code completely, the effort will be well worth your while.)

Throughout this article, we borrow heavily from the "right-brain" learning paradigm together with your existing classic ASP skill set to explore and understand how to code in ASP.NET. This technique allows us to focus on concepts without getting bogged down in details that you as a classic ASP developer are already familiar with. Consequently, in this first part we generally restrict ourselves to partial code listings. Once the main ideas have been fixed, then in the subsequent parts of this series, we will illustrate how to then write a complete ASP.NET web page.

Let's Start with HTML

Say we want to display a list of books and their prices in a table like the one shown below:

ID Book Price ($)
1 ASP.NET in a Nutshell 44.95
2 ASP.NET Cookbook 39.95

The HTML code for this table is:

<table border=1> 
    <td> ID</td> 
    <td> Book</td>
    <td> Price ($)</td> 
      <!-- TABLE ROW for First Book --> 
      <td> 1</td> 
      <td> ASP.NET in a Nutshell</td> 
      <td> 44.95</td> 
      <!-- TABLE ROW for First Book Ends --> 

  <!-- TABLE ROW for Second Book --> 
      <td> 2</td> 
      <td> ASP Cookbook</td>
      <td> 39.95 </td> 
  <!-- TABLE ROW for Second Book Ends --> 


Every time we need to remove or add books, we have to manually add rows to the table. This can be very tedious and a nightmare to maintain. With classic ASP, we can use a do-loop to go through the records extracted from the database and build the rows:

Listing 2: Table in ASP

    '################# Server Side Code Block ##############
    ' Connect to DB ' create the connection and recordset objects
    Dim objConn 
    ' create the connection and recordset objects
    set objConn = Server.CreateObject("ADODB.Connection") 
    ' Open the connection to the DB
    ' SQL Server DB connection _
      "Provider=SQLOLEDB;Server=(LOCAL);" + _
      "Integrated Security=SSPI;Initial Catalog=MySite.COM;" 
    dim objRS set objRS = Server.CreateObject("ADODB.Recordset") 
    objRS.ActiveConnection = objConn 
    set objRS = objConn.Execute("select * from Books") ' Extract records from database
    dim outputstring 
    ' format the header of the table 
    outputstring = outputstring & "<tr><td>ID" + _
    ' ############# DO LOOP for the TABLE ROWS for the BOOKS ##### 
    do until objRS.EOF
      outputstring = outputstring & "<tr>" 
      outputstring = outputstring & "<td>" & _ 
              objRS.Fields("ID").value & "</td>" 
      outputstring = outputstring & "<td>" & _ 
              objRS.Fields("Title").value & "</td>" 
      outputstring = outputstring & "<td>" & _
              objRS.Fields("Price").value & "</td>" 
      outputstring = outputstring & "</tr>"
    ' ########### End of DO LOOP for the BOOKS ###################

    ' Clean up 
    set objRS = Nothing
    set objConn = Nothing 
    '################# Server Side Code Block Ends ########
  <!-- -------------Presentation HTML Block-------------- --> 
  <table border="1">
  <%= outputstring %> <!-- Mixing server side code with HTML --> 
  <!-- ------------- Presentation HTML Block Ends -------- --> 

Related Reading

ASP.NET in a Nutshell
By G. Andrew Duthie, Matthew MacDonald

Notice, however, that VBScript is intermingled with pure or straight HTML. While this mixing may not look so bad in the toy example above, it can get intricate quite rapidly in fairly large web site implementations. Maintaining this type of code is no easy feat. Thus, in one sense, we have come back full circle with code that is hard to maintain.

Can we do even better and totally separate the server-side script code from the presentation code? Can the presentation code consist only of content markup tags and not have any "inline" shortcuts (<%= ...%>) for the ASP Response.Write method? Can we go even further and not even bother to write any HTML (such as table rows and other tags) in the server-side-script part of the page? If we are able to achieve this separation, then in our server-side code we need only focus on the business logic, while in the lower presentation block, we limit ourselves to markup-type issues.

In other words, we want a tag that is "intelligent" enough to know how to render the records extracted from the database assigned to it without us having to explicitly write the markup HTML in our code. By simply associating the recordset en masse to this "intelligent" tag, it should "know" that each record should be rendered as a HTML table row, and that each field forms the HTML table column. Writing a recordset to a table is very common; there already is such a tag defined: <asp:DataGrid> ... </asp:DataGrid>.

These "intelligent" presentation tags or elements allow us to neatly structure our code as follows:

  • Extract records from the database (similar to classic ASP, though code details differ).
  • Associate the entire recordset to the <asp:DataGrid> ... </asp:DataGrid> element.

The <asp:DataGrid> ... </asp:DataGrid> presentation tag is itself defined in the markup section with the rest of the HTML for the page. The new tag is accessed programmatically in the script block to associate the records using its ID attribute. Conceptually, programmatically accessing an element is similar to the way we do it in JavaScript/DHTML. The primary difference is that in JavaScript/DHTML, the code is executed on the client side. In ASP.NET, the code is executed by the server before delivering the HTML stream to the browser.

We place the <asp:DataGrid> ... </asp:DataGrid> element within a <form runat="server"> ... </form> container and specify a runat="server" attribute on the <asp:DataGrid> ... </asp:DataGrid> element. The runat="server" makes the corresponding elements "available," or accessible in the script block.

Now, here is where the magic of ASP.NET comes in. When assigning data records to a datagrid in ASP.NET, we do not write any HTML. Instead, all we do is specify that the datagrid is populated from the records we pulled from the database. Then, ASP.NET produces the appropriate HTML to display the records.

Pages: 1, 2

Next Pagearrow