1.2 ASP 4.0


Although ASP.NET is not technically labeled ASP 4.0, in many ways it is just that ”the next version of ASP. Because most people starting to work with ASP.NET come from an ASP background, we start our exploration by describing the similarities shared by the two technologies. Listing 1-1 shows a simple ASP page that intermingles server-side JavaScript with static HTML. Note that several server-side coding techniques are demonstrated in this file. There is a script block marked with the runat =server attribute containing a function called Add . The server-side evaluation syntax " <%= " is used to invoke the Add method and output the results of the expression to an h2 tag. The server-side script syntax " <% " is used to programmatically generate ten rows in a table, and finally, the intrinsic Response object is used to programmatically add a final h2 tag to the bottom of the page.

Listing 1-1 Sample ASP Page
 <! File: test.asp > <%@ language=javascript %> <script language='JScript' runat=server> function Add(x, y) {   return x+y; } </script> <html> <body> <h1>Test ASP Page</h1> <h2>2+2=<%=Add(2,2)%></h2> <table border=2> <%   for (var i=0; i<10; i++) { %>   <tr><td>Row<%=i%> Col0</td><td>Row<%=i%> Col1</td></tr> <%   } %> </table> <%   Response.Write("<h2>Written directly to Response</h2>"); %> </body> </html> 

All these server-side programming techniques are supported in ASP.NET as well. In fact, if you take this file and simply change the extension from .asp to .aspx, you will find that it behaves exactly as the .asp version did. What is really happening under the covers when these two pages are accessed is dramatically different, as we will see, but on the surface, many traditional ASP pages can be brought forward as ASP.NET pages with no modifications.

In ASP.NET, we are no longer constrained to the two scripting languages available in traditional ASP: VBScript and JScript. [3] Any fully compliant .NET language can now be used with ASP.NET, including C# and VB.NET. To see an example, we can rewrite the ASP page presented in Listing 1-1 as an ASP.NET page using C# as the server-side language. Although it is not strictly required, we include the language preference within a Page directive, which is where most of the page-level attributes are controlled for ASP.NET pages. Listing 1-2 shows the page rewritten using C#, complete with an ASP.NET Page directive.

[3] Although, as we have seen already, JScript is a fully supported .NET language and can be used in ASP.NET pages. VBScript, in contrast, is not directly supported in ASP.NET, although full-fledged Visual Basic .NET can be used.

Listing 1-2 Sample .aspx Page
 <! File: test.aspx > <%@ Page Language='C#' %> <script runat=server> int Add(int x, int y) {   return x+y; } </script> <html> <body> <h1>Test ASP.NET Page</h1> <h2>2+2=<%=Add(2,2)%></h2> <table border=2> <%   for (int i=0; i<10; i++) { %>   <tr><td>Row<%=i%> Col0</td><td>Row<%=i%> Col1</td></tr> <%   } %> </table> <%   Response.Write("<h2>Written directly to Response</h2>"); %> </body> </html> 

1.2.1 Compilation versus Interpretation

The first time you access the ASP.NET page shown in Listing 1-2, the most remarkable thing you will see differentiating it from the traditional ASP version is the amount of time it takes for the page to load. It is slower. Quite a bit slower, in fact. Any subsequent access to that page, however, will be markedly faster. The overhead you will see on the first access is the launching of the ASP.NET worker process plus the parsing and compilation of the .aspx files into an assembly. This is in contrast to how the ASP engine executes server-side code, which is always through an interpreter (JScript or VBScript).

When a traditional ASP page is requested , the text of that page is parsed linearly. All content that is not server-side script is rendered as is back to the response. All server-side script in the page is first run through the appropriate interpreter (JScript or VBScript), the output of which is then rendered back to the response. This architecture affects the efficiency of page rendering in several ways. First, interpreting the server-side script on the fly is less efficient than executing precompiled code on the server. As a side effect, one common optimization for ASP applications is to move a lot of server-side script into precompiled COM components to improve response times. A second efficiency concern is that intermingling server-side evaluation blocks with static HTML is less efficient than evaluating a single server-side script block, because the interpreter has to be invoked over and over again. Thus, to improve efficiency of rendering, many ASP developers resort to large blocks of server-side script, replacing static HTML elements with Response.Write() invocations instead. Finally, this ASP model actually allows different blocks of script within a page to be written in different script languages. While this may be appealing in some ways, it also degrades performance by requiring that a particular page load both scripting engines to process a request, which takes more time and memory than using just one language.

In contrast, ASP.NET pages are always compiled into .NET classes housed within assemblies. This class includes all of the server-side code and the static HTML, so once a page is accessed for the first time (or any page within a particular directory is accessed), subsequent rendering of that page is serviced by executing compiled code. This eliminates all the inefficiencies of the scripting model of traditional ASP. There is no longer any performance difference between compiled components and server-side code embedded within a page ”they are now both compiled components. There is also no performance difference between interspersing server-side code blocks among static HTML elements, and writing large blocks of server-side code and using Response.Write() for static HTML content. Also, because the .aspx file is parsed into a single code file and compiled, it is not possible to use multiple server-side languages within a single .aspx file.

There are several other immediate benefits to working with a compilation model instead of an interpreted one. In addition to improved performance over the interpreted model, pages that are compiled into classes can be debugged using the same debugging tools available to desktop applications or component developers. Errors with pages are generated as compiler errors, and there is a good chance that most errors will be found at compilation time instead of runtime, because VB.NET and C# are both strongly typed languages. Plus, all the tools available to the .NET developer are applicable to the .aspx developer. In fact, this distinction between Web application script developers and component developers, which has traditionally been very clear, is gone completely. Web developers using ASP.NET are constructing classes and building hierarchies using the same technologies and languages as their component developer peers, even when they are simply writing .aspx files with embedded server-side code. This is a fundamental shift in design from traditional ASP and bears repeating. Whenever you author an ASP.NET page, you are authoring a new class.



Essential ASP.NET With Examples in C#
Essential ASP.NET With Examples in C#
ISBN: 0201760401
EAN: 2147483647
Year: 2003
Pages: 94
Authors: Fritz Onion

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net