| |
ASP.NET: Prepare for a New World
David Chappell - October
12 , 2001
Sometimes Microsoft changes a technology's name, but doesn't
change the technology itself. A few years ago, for instance, the
company renamed "OLE" as "ActiveX", but the underlying technology‹COM‹didn't
change at all. In other situations, Microsoft leaves a name more
or less the same while radically revamping the technology it identifies.
ASP.NET is a shining example of this second phenomenon. Although
the name sounds familiar, it is in fact very different from ASP.
The clearest way to get a sense of this is to describe what happens
when an ASP.NET page is accessed from a browser. Here's a very
simple .aspx page, the ASP.NET equivalent to ASP's familiar
.asp pages:
<html>
<script runat="server" language="vb">
Sub ShowNumbers()
Dim I As Integer
For I = 0 To 5
Response.Write(I)
Next
End Sub
</script>
The date and time: <% =Now() %>
<hr>
Some numbers: <% ShowNumbers() %>
</html>
Just like a traditional ASP page, ASP.NET's .aspx pages can
contain HTML, plain text, and code wrapped in either a <script>
element or "<% . . . %>". In fact, the previous page could
almost be an .asp page: Get rid of the DIM statement, change the
language to "vbscript", and it would work fine with traditional
ASP. Yet what happens when this page is executed by ASP.NET is very
different from what happens when traditional ASP executes a page.
If this were an ASP page, the code it contains would be interpreted
by the server, with the output it generates inserted in the stream
of data sent to the browser. The text and HTML in the page would
be passed through directly to the browser unchanged. If the page
used COM objects, they would be written and compiled in some other
language, then created and used via the standard COM mechanisms.
Accessing this page through ASP.NET results in a completely different
execution process. ASP.NET applications are .NET Framework applications,
which means that they're based on the Common Language Runtime
(CLR). Because of this, every .aspx page is automatically turned
into a class the first time it's accessed by a client. This
new class inherits from a standard Page class defined by the .NET
Framework class library, and different pieces of the .aspx page's
contents are inserted into this class in different places. For instance,
any code contained within <script> elements is inserted into
the class itself. In this case, the page's simple ShowNumbers
method becomes a method in the generated class. The rest of this
page, including any text, HTML tags, and code wrapped in "<%
. . . %>", gets dropped into a single method called Render in
this class. The class is then compiled and packaged into an assembly,
the container used by .NET to hold compiled code. Once this assembly
has been created, it's used to handle all future requests for
this page. If the page is changed, the process happens again and
a new assembly is generated.
Understanding how a traditional ASP page generates its output is
easy: The page is processed sequentially. As we've already
seen, though, this isn't the case in ASP.NET. Given that each
page is turned into a class before it's executed, how does
execution happen? The answer is that in place of the simple sequential
processing of traditional ASP, ASP.NET uses an event-driven model.
When a page is accessed, the assembly generated from that page is
executed, and an instance of that assembly's page class is
created. This page object receives a series of events, such as Render.
Each event is handled by an appropriate method; so, for example,
the Render method handles the Render event, allowing a page to display
some or all of its output. Code in the .aspx page can also contain
methods that handle these events, and each of those methods can
produce output that gets sent to the client's browser. Once
all events have been handled, the page object is destroyed.
Event-based programming will be new to many ASP developers, and
understanding it will require some work. Yet a primary goal of Web-scripting
technologies such as ASP.NET is to create effective user interfaces.
User interfaces by their nature are event-driven, and so it makes
sense to apply this model here. In fact, event-driven user interfaces
have always been the norm for Windows applications. But along with
events, there's another idea that's long been popular
in building Windows GUIs: packaging discrete chunks of reusable
functionality into controls. Each control commonly provides some
part of a user interface, such as a button or text box, and so they
can be combined as needed to more easily build an effective GUI.
Since ASP.NET has adopted the notion of event-based programming,
why not introduce reusable interface components to the Web as well?
This is exactly what ASP.NET's Web controls do. They're
conceptually close to traditional Windows controls, in that each
one provides its own user interface and carries out its own function.
Unlike Windows controls, however, Web controls run on the server‹they
are classes that become part of a page class‹and they produce their
user interfaces by generating appropriate HTML for a browser. ASP.NET
provides a large set of standard Web controls, including common
atoms of GUI design such as Button, TextBox, CheckBox, RadioButton,
and ListBox.
Microsoft's original Active Server Pages technology was a
huge hit. A primary reason for this was that it was incredibly easy
to use. True, this initial ease of use tended to devolve into unmaintainable
code for applications of any size, but the barriers to entry for
this technology were very low. ASP.NET provides much more than the
original ASP, but to do this, it adds complexity. In fact, using
ASP.NET effectively really requires understanding the CLR because
all code must be written in a CLR-based language such as VB.NET
or C#. Classes, events, inheritance, and a host of other more advanced
concepts will descend on unsuspecting ASP developers like fog on
a San Francisco evening. While writing real ASP applications requires
some technical knowledge‹COM components aren't so simple either‹ASP.NET
asks even more of its developers.
For traditional ASP developers, ASP.NET is a new world. Some parts
will look familiar, and much of the knowledge picked up in the old
world will be useful in this one. Much of it won't, however,
and some might be downright misleading. Because of this, the best
way to understand ASP.NET isn't to think in terms of the technology
it replaces. The best approach is to first understand the .NET Framework
in general and then to grasp how ASP.NET builds on this foundation.
ASP was nice, but it's over. Get used to ASP.NET.
|
|
Website
design and development by kmcreative.
KMCREATIVE is a Silicon Valley based graphic design firm specializing
in corporate collateral, web design, web development, identity,
medical illustration and product illustration.
|
|
Back
to Top.
