For those who have done any event-driven programming a web form is analogous to a Windows form. This means we can write our code in event handlers that respond to user actions on the form - such as a button click. Amazingly, the fact that the interface of the web form (in the browser) is not directly connected to the event handlers (on the server) is not a problem because ASP.NET handles all of this rather tricky business automatically. This means the developer no longer has to worry about browser to server round-tripping, page refreshes, and handling the state of the controls that appear on the web form. The developer can get on with the important business of writing the code to react to the events. See the article "An Example ASP.NET Web Form for Data Input" for a demonstration of this process.

The ASP.NET Event driven processing engine is a major shift forward compared to the linier processing model used by ASP version 3 (and PHP!). In ASP 3 the output page is built from top to bottom, often with ASP program code interspersed with HTML. In ASP.NET, on the other hand, the ASP code can be quite separate from the HTML. Visual Studio .NET allows us to develop with separate 'code behind' files - written in C#, Visual Basic, or what ever other language we prefer. This is excellent because it means there is a clear separation between the design and the code on a page. It is less confusing (have you ever tried to read a large ASP 3 or PHP input validation page?), and it means that designers and coders can work on the same page much more easily (if they are different people that is!).

These 'code behind' files are potentially just the interface or event 'hooks' to what could be an entire enterprise application, built from business classes, database classes, backend database services, external web services, e-commerce facilities etc... The 'code behind' classes must be compiled; this means we get good performance improvements with ASP.NET compared to ASP 3. They are compiled in to a "DLL" (project Assembly) that is simply put in the 'bin' directory of the web server. The great news for deployment purposes is that this "DLL" does not need to be registered, and in addition can even be 'hot' swapped for a new version without bringing the server down! Note, we do have the option of not working in 'code-behind' mode. In this case the ASP code is included inline with the HTML interface code as before, and must therefore be interpreted at runtime.

For the previous example to work, we must have created this tag within the separate HTML document with the setting "runat=server":

  <h1 id="ohdr_text" runat="server"></h1>

This is called a ASP.NET "HTML control" ! It is different to a regular HTML tag because our ASP.NET 'code behind' file needs to access it. The control is accessed as an object, in exactly the same way as we access items in the DOM (Document Object Model) in client-side script (DHTML). So not only can we change the content but we can also change any other properties relating to that HTML tag. ASP.NET HTML control objects are closely related to the underlying HTML element (tag) - just like the DHTML objects and their associated HTML elements.

ASP.NET also gives us another group of controls to work with, named ASP.NET "Web Controls". In the previous exampe the text box is a Web Control :

  <asp:textbox id="otxt_field" runat="server" autopostback="True"></asp:textbox>

The whole set of HTML control types (button, text box, label, drop-down list etc...) are available as Web Controls, plus a whole host of extended functionality controls - such as Calendar, DataGrid, and Validation Controls. Web Controls expose a different object interface compared to the HTML controls, not necessarily so closely linked to the DHTML object model. Often they need to because of their enhanced functionality. The clever bit about Web Controls is that their rendering engine varies their output dependent on the client browser detected. For example, the more complex web controls may cause DHTML to be included in the page if IE5+ is detected, otherwise the control might be implemented using HTML only forms. It is even possible to get Web Controls to output as WML (for mobile devices) or XML.

User Controls ('ascx' files in .NET) are created just like a web form. We design the interface and write what ever event-handling code we want in the code behind file... data access layer, business validation rules etc... We save this ascx file, or we can even convert an existing web form in to an ascx. Now we can drag and drop our custom form on to any other web forms. Thus we have a reusable control. If we need to change it, we change it once and that change is inherent on all pages that the control appears on... (of course, because it is the same code!). If we just want to replicate a static block of HTML, then we can use 'server side includes', but if we want to effect the control's output dynamically or have it react to events then a user control offers much more power.

ASP.NET Web Forms can produce impressive results, but it is best to understand them in depth to avoid potential pitfalls. We need to be wary of 'automatic postbacks' and any browser to server round trips for performance / scalability reasons. Do we really want our 80Kb web page to be refreshed everytime the user clicks on a control? Maybe its best to host the interactive part of the page in a HTML IFrame? Maybe we can employ output caching for some pages, or even cache a user control separately (known as 'fragment caching'). Should we use 'Viewstate' for our web forms and if so, what are the security implications (Viewstate is the method by which ASP saves the form's state in the HTML page)?. Given a good level of understanding, ASP.NET web controls do offer the developer a new level of power in the creation of interactive web applications.