ASP.NET: Prepare for a New World
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.