Structure of Pre–ASP.NET Pages
As you will soon see, the structure of a page in previous versions of ASP is quite different from that of an ASP.NET page. Pre–ASP.NET pages are severely lacking in the structure department. Although there are a few ways to make your ASP code slightly structured, several lines become blurred. This section talks about a few of the common problems that developers run into when developing with previous versions of ASP.
The Great Monolith
So how do you currently write ASP pages? Well, if you’re anything like us—and let’s hope that you’re not, in some respects—your ASP pages have the structure of a 50-story skyscraper made out of Popsicle sticks. Now, don’t get us wrong: A certain degree of structure can be attained with standard ASP programming, but it is not the type of structure and organization that is obtained with a real programming language. The fact is, there just isn’t any great way to write extremely structured code in ASP like there is in Visual Basic or C#.
For example, if you have a series of “global” functions that are used throughout your application, you probably shove them into an .asp file and use the #include file directive to bring them into the rest of your .asp pages to avoid code repetition. Although this might get the job done, you might not realize what is happening behind the scenes with the script parser.
By including pages in this manner, they simply get tacked on at the point where you include them. This means that the entire included page is parsed and processed even if only a single constant declaration, for example, is used out of it. Luckily, because ASP.NET uses true, compiled languages, it gets you out of this bind.
Pasta Nightmare
You probably have heard the expression “spaghetti code,” which is code that lacks structure and clear separation among the main elements. Traditional ASP code is the epitome of spaghetti code. Code does not get much more tangled up in any language quite like it does in ASP. The main reason for this is the lack of a distinct separation between client-side presentation code and server-side business/logic code.
In the traditional ASP environment, you generally wind up mixing your HTML presentation layer with your VBScript server code, as shown in Listing 2.1.
Listing 2.1. A Typical ASP Page
<HTML>
<BODY>
<%
Dim pvNameArray
pvNameArray = Array("Jonathan Goodyear", "Brian Peek", "Brad Fox")
Response.Write "<select name='Author'>"
For i = 0 to 2
Response.Write "<option value=' " & i & " '>" & pvNameArray(i) & "</option>"
Next
%>
</BODY>
</HTML> |
As you can see, instead of a very clear distinction between the HTML that creates
the drop-down box and the code that fills it, the two are very much intertwined. This type
of coding conflicts with the basic principles of “three-tier” programming. The theory
of three-tier programming is that there is a distinct separation among the client
presentation layer, the server business logic layer, and the database layer. In ASP, the
lines between these layers can very easily become blurred. In the previous example, you
are doing work that could and should be performed at the business logic layer instead of
at the client layer.
The Inclusion Conclusion
Code reuse is a very important part of
writing any type of application. No one wants to rewrite the same code to perform the same
function time and time again. Most programming languages provide a way for developers to
include libraries of functions in their applications, saving them from having to reinvent
the wheel every time they need to do something simple. ASP allows for something similar,
but it has one very major flaw.
For example, imagine that you are writing a screen for an
application that needs to pull several ADO recordsets from a database and display them to
the user in a table. The code to grab the recordset from the database might look similar
to Listing 2.2.
Listing 2.2. Code to Retrieve an ADO Recordset
<%
Const adLockReadOnly = 1
Const adLockPessimistic = 2
Const adLockOptimistic = 3
Const adLockBatchOptimistic = 4
Const adOpenForwardOnly = 0
Const adOpenKeyset = 1
Const adOpenDynamic = 2
Const adOpenStatic = 3
Const adCmdText = 1
Const adCmdTable = 2
Const adCmdStoredProc = 4
Const adCmdUnknown = 8
%>
<HTML>
<BODY>
<%
Set poCon = Server.CreateObject("ADODB.Connection")
poCon.Open "Driver={SQL Server};Server=(local);Database=Pubs;UID=sa;PWD="
Set poRS = Server.CreateObject("ADODB.Recordset")
poRS.Open "SELECT * FROM authors ORDER BY au_lname", poCon, adOpenKeyset,
|
Every time you need to retrieve an ADO recordset, you must rewrite the code that
creates the connection object, opens the connection, creates the recordset object, and
opens the recordset. So how do you solve this in traditional ASP? Well, you can write some
generic routines that open connections or open recordsets and put them in a separate file.
Then you can use the #include file="<filename>" directive to pull this file into the page
that is about to be displayed to the user. However, this scenario contains one major
downfall: Every page that is included in this fashion is parsed in its entirety. So, if
you created an ASP page that included all your database routines for your entire
application, and you then included it on a page on which only one of the functions is used
, the ASP processor still would parse the entire page and work its way through all the
unused code before giving you what you need. Without a doubt, this is terribly inefficient
. So how do you combat that in ASP?
The way to currently work around this problem in ASP is
to move your business logic code into components. From ASP, you can create an instance of
your component and call methods on it just as you would from Visual Basic. With this
approach, you gain the benefit of a compiled language—that is, increased speed and
decreased memory usage. However, this approach suffers from a number of downfalls. First,
you will be forced to compile your code every time you want to make a change instead of
just editing a text file. This can become quite cumbersome if your site undergoes many
changes before becoming stable.
Second, when the object is instantiated in your ASP page,
you get only a generic object that pretends to be the real object. Because of this, every
time you call a method on that object, the GetIDsOfNames API call is fired to locate the
position of the method in the object’s vtable. This is a definite performance hit.
Finally, deploying components can be a difficult process. Access to the server is required
to register the resulting DLLs. This runs contrary to the simple process of copying
assemblies to the server in the case of a ASP.NET application, which can even be done
through a simple shared drive or folder.