Classic ASP vs. ASP.NET
Introduction
This article explains the difference between the Classic ASP and ASP.Net and also
focuses on the new features in ASP.NET. Let's discuss the differences between these two in detail:
Process Isolation
ASP is running under the inetinfo.exe (IIS) process space and hence susceptible to application
crashes due to that the IIS needs to be stopped or restarted.
ASP is related to the process isolation setting in IIS.
Where as, ASP.Net process is separate from inetinfo.exe (IIS process).
Though the entry point into a ASP.Net application is still IIS but it is not
related to the IIS process isolation settings.
Non-MS Platform Support
Classical ASP has no mechanism of running itself on non- Microsoft technology
platforms like the "The Apache Web Server" (there are some third party products, like ChiliSoft) but, ASP.NET could be run on non-
Microsoft Platforms also. Cassini is a sample Web server produced by Microsoft which,
among other projects, has been used to host ASP.NET with Apache.
Multi Language Support in WebPage
Only VBScript and Javascript were available for scripting in ASP where as, in ASP.NET
there are no such restrictions. The .NET compliant language can be used with ASP.NET
including several like C# and VB.NET, where both of them are server-sided languages.
Interpretation Vs Compilation
In ASP, an interpreter like Jscript or VBScript is used to execute the server-side code.
When an ASP page is requested, the text of that page is parsed linearly.
The content that is not server-side script is passed back as it is to the response.
Where as, the server-side script in the page is executed through the appropriate interpreter,
and the output is then submitted back to the response.
The efficiency of page rendering is affected by this architecture in several ways.
Firstly, on the go interpreting of the server-side script.
A common optimization for the ASP applications for this side affect is to move a mass of
server-side script into precompiled COM components to improve the response time.
Secondly, the intermingling server-side evaluation blocks with static HTML is another
efficiency concern. It is less efficient than the evaluating a single server-side blocks
because the interpreter has to be invoked time and again.
As a rescue, many ASP developers resort to large blocks of server-side script for
replacing static HTML elements with Response.Write() invocations instead. Eventually,
this ASP model permits the inclusion of different blocks of scripts within a page to be
written in different script languages. This may appeal in some ways but it also reduces
performance by requiring that a particular page load both scripting engines to process a
request that consumes more time and memory if compared to just using one language.
But in ASP.NET, the pages are always compiled into .Net classes housed within
assemblies. This class includes both the server-side code and static HTML, so when the
page is accessed for the first time, subsequent rendering of that page is serviced by
executing the compiled code. All the inefficiencies of the scripting model of traditional
ASP are eliminated by this. No longer had any performance difference between compiled
components and server-side code embedded within a page observed. Both of them are
compiled assemblies now. 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. The .aspx file is parsed
into a single code file and compiled, its not possible to use multiple
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.
Debugging benefits
In classic ASP, debugging is a tough task because of limited support due to the
interpreted model. In contrast, not only ASP.NET improves the performance over the
interpreted model but also provides debugging tools for component developers and pages compiled into classes. The page errors are
generated as compiled errors and there is a fir chance that most of them will be
discovered at the compilation time instead of runtime due to the fact that VB.Net and C#
are strongly typed languages. In addition to this, the tools available to the Windows Forms .Net developer
are applicable to the ASP.NET developer.
Server-Side code placement Web Page
In ASP pages you might include the executable code outside the scope of a function
within a script block marked as "runat=server" and you may also define a function within
a pair of server side script tags. Where as in ASP.Net the former is no longer supported
and the latter is also not possible.
A default constructor is provided by the generated class definition, and it would be a
compiler error if you try to write a default constructor. For this, you can choose the
alternative method of separating the layout from the page logic which consequently gives
you a complete control over the class definition. This method is called code-behind.
Deployment Strategies
The components used by pages and deployed in this manner were difficult to update or
replace in the Classic ASP. You are required to shutdown the IIS because of the fact that
while the application was functioning, it referred to the component file for replacement.
So, after taking your web server temporarily offline, you had to replace the file and then
restart IIS. But, in ASP.NET it aimed to get rid of the need to stop the functioning Web application whenever the
components needed to be updated or replaced.
To attain this, the designers of ASP.NET had to ensure two things: first, that the running
application not hold a reference to the component file and second, that whenever the
component file was replaced with a new version, that new version was picked up with
any subsequent requests made to the application. Both of these goals are achieved by
using the shadow copy mechanism provided by the Common Language Runtime (CLR).
New Page Directives
In ASP, the directives are required to be placed on the first line of a page within the same
delimiting block. For instance:
<%LANGUAGE="VBSCRIPT" CODEPAGE="932"%>
While ASP.NET required you to place the Language directive with a Page directive, as
follows:
<%@Page Language="VB" CodePage="932"%> <%@QutputCache Duration="60"
VaryByParam="none" %>
It could be more than one directive lines, which depends on your need. The standard practice
is to place the directives in the beginning of the file but you can place it anywhere in your
.aspx file.
Threading Issues
The threading model of COM object created using VB within a web-based application is
STA (Single Threaded Apartment). ASP worker thread resides in its own STA and hence the compatibility is fine in
this case with a little performance hit.
But in ASP.NET, threading model is the Multiple Threaded Apartment (MTA). This means
that components that you are using were created for the Single
Threaded Apartment (STA) will no longer perform or function reliably without taking
some extra precautions in ASP.NET. This includes, but is not limited to, all COM
components that have been created using Visual Basic 6.0 and earlier versions. You will
be glad to hear that you can still use these STA components without having to change any
code. What you need to do is include the compatibility attribute aspcompat=true in a
<%@Page> tag on the ASP.NET page.
For example, <%@Page aspcompat=true
Language=VB%>.
Using this attribute will force your page to execute in STA mode, thus
ensuring your component will continue to function correctly. If you attempt to use an
STA component without specifying this tag, the run time will throw an exception. Setting
this attribute to true will also allow your page to call COM+ 1.0 components that require
access to the unmanaged ASP built-in objects. These are accessible via the ObjectContext
object. If you set this tag to true, your performance will degrade slightly.
Validation & Browser scripting capabilities
There is no inbuilt facility for the validation of controls in the Classic ASP. For
example, checking whether a textbox is left blank, or a combo is selected or not, or
if a phone number does not fit a particular pattern for area etc.
These kinds of validations required the user to write the client side Javascript
code.
It was not less than a headache for the developer to cater the client and server side
validations.
What added to the burden on the developer was the Javascript code to fit a
particular Browser. Specific code had to be written to fit a set of browsers and it
consumed a lot of time.
But in ASP.NET, In built validation controls are provided which are easy to implement
and the developer has to worry the least.
The features provided by ASP.NET validation controls:
Browser Independent coding: Developer does not have to worry about the
browser and how controls would render to.
Client-Side or Server-Side: The Validation Controls manage the code checking if
the client side code is disabled the validation is done on the server side.
Rich Validation set
There are few types of validation which cater to the needs of the validation requirements:
RequiredFieldValidation Control - Requires that the control not be left blank.
CompareValidator Control - Used to compare Data in Two Controls
RangeValidator Control - Used to check for Range validation (also supports
various data Types - Date, string etc...)
RegularExpressionValidator Control - Used to check the complicated patterns in
the user input.
CustomValidator Control - The final control we have included in ASP.NET is one
that adds great flexibility to our validation abilities. We have a custom validator
where we get to write out own functions and pass the control value to this
function.
This control also provides Client side and server side validation of which the Server side
validation could be a different function altogether.
Validation Summary
The validation summary control will collect all the error messages of all the non-valid
controls and put them in a tidy list. The list can be either shown on the web page (as
shown in the example above) or with a popup box.
Conclusion
Classic ASP goes a long way toward simplifying Web programming. It is demanding
when it comes to writing a new DDL from the very beginning as compared with the
easier task to write some HTML and mingle it with a script. But then Classic ASP is not
fee of issues. The ASP pages are mass of unstructured code. It can be compared to the
early days of BASIC programming, where achieving a task quickly was possible but the
resultant code was often hard to follow. The object model of ASP has multiple inherent
or global objects. For instance, for the generation of the content of an HTTP request,
script code is written and the content is send to the client using the intrinsic Response
object. In the guaranteed situations where only one client is involved in talking to your
Web application, this isn't much of a problem. But not many web applications guarantee
this. And the reason for this is the way ASP is organized by these intrinsic objects.
ASP.Net improves the classic ASP. The same intrinsic objects still remain in ASP.Net
and the scripting can be added anywhere on the page per you requirement. In fact,
ASP.NET easily manages and runs most of the ASP pages with .aspx extension.
ASP.Net introduces a lot of new features. Like all the components within .Net, ASP.Net
pages too are compiled into the assemblies, which give a performance and security edge.
Further, it supports the usage of any .Net language. This means there is no restriction
over the use of JavaScript or VB Script on your Web pages. Now, you have an option to
use more structured languages.
ASP.Net opens up a whole new programming model with the blend and combination of
Web forms, server-side controls, data binding, and Web services. |