Room for reference
June 09, 2004
  ASP & ASP.NET: The Differences..
I thought like, providing the differences (that I Know!) of classic ASP and ASP.NET would be helpful to many. Today's entry here is intended for that..


Objects Support
Classic ASP
6 objects (Request, Response, Application, Session, Server & Error), which are components that make web-development dynamic. The objects are interface based, not object based so are often called components. Can be extended with COM objects or COM+ (including transactions) that can interact with ASP objects. Supports default interface COM programming, not multiple interfaces. COM and COM+ objects tend to need GUI tools that automate their creation.

Can consume COM and COM+ objects. Can be used to create objects that support interfaces and inheritance. Languages can inherit and override methods of objects created in DIFFERENT languages. These can be built with text editors and GUIs are a convenience not a necessity. Can make its components into SOAP listeners and proxies with trivial amounts of work by just setting a few attributes.
Language Support:
Classic ASP
2 built-in script languages (VBscript, Jscript) that are NOT compiled. some 3rd party languages: Perlscript, Python but not so robust and actually tend to crash the server.

3 built in COMPILED languages (has NO scripting languages): VB7 / VBNET, C# and JScript / JSNET
----------------------------------------------------------------------------------Database Support:
Classic ASP
Database support via ADO which communicates with ODBC and OLEDB databases. Most database display is done through recordsets and loops. Most database manipulation requires code coupled to back-end database that may fail if drivers are switched and needs to be written carefully.

Database support via which communicates with ODBC and OLEDB databases, XML Streams, Binary Streams but is loosely coupled so differences between database vendors do not EVER affect programming model. Database display NEVER involves loops. Templates, grouped controls, Grids and many other declarative structures eliminate need for loops and flexibility is provided so programmer can control all interaction between templates declaritivity.
Classic ASP
Scalability without work is limited because 2 of the core objects (session, application) don't scale on web-farms. Those objects must be replaced with home-brewed or commercial objects if that functionality is wanted on webfarm. Scalability, multi-tier application building and transactional applications are possible to be build but the programmer has few tools to make the task simple. It is just hard work and the programmer must have experience building such systems in the past to build an effective one today.

Sessions and all features were built with web-farms and supports "web gardens" (1 computer with multiple CPUs) as assumed environment.
Several kinds of caching reduces database access and code execution dramatically without requiring page-level changes.
----------------------------------------------------------------------------------Browser Support:
Classic ASP
Browser neutral.

Validators and built-in components use detection to render GUIs that behave consistently on a variety of browsers. has lots of facilities so that controls can detects the browser and renders the GUI very differently depending on what browser requests the page without having to expose this sensing to higher level callers.
----------------------------------------------------------------------------------Execution Environment:
Classic ASP
Tightly coupled to IIS. The ASP engine is undocumented so that it cannot easily be extended and only low-level ISAPI filters can be created to accomplish tasks that ASP will not support easily.
In "classic ASP" the first person to access a script compiles it but if the compiled script cache fills scripts are removed and if a machine physically restarts or a service restarts the compilation process is triggered by first user access.

Loosely coupled to IIS to ensure that it runs on any webserver without requiring any IIS infastructure. Extremely extensible and high-level utilities called HTTP Handlers can accomplish the most complex of tasks without inheriting the ENTIRE ASP+ infastructure or bloat. Components and scripts have their compiled image written to disk so that compilation persists.
Classic ASP
Once an application is created it's settings reside in the Windows Registry, Binary Metabase, MTS catalogs, IIS settings. Transferring /copying a app from server is a complex tedious job with few automatic tools. Component registration is done via a variety of doftware packages all of which require a system adminstrator run these utilities.

Huge complex applications store their settings and components in ASCII files and copying these ASCII files from server to server will result in a perfectly deployed application with no effort. Their are no component registration tools because components do not make any registry entries nor do they need to be compiled before being copied to server. All configuration/security options rely in ASCII/XML files.
----------------------------------------------------------------------------------Versioning approach:
Classic ASP
New versions of components required stopping and starting the server. Once new component versions were deployed, old versions were replaced.

If a component is rewritten to have a new version, the next user accessing a page that accesses the new version runs on a new thread. The previous versions and new versions co-exist in memory since a fully running component live on a thread. Of course the worker process will eventually finish all user requests communicating with old component and quietly quit wasting memory on it. Aspx or any programs can target any version of an assembly since side-by-side execution is supported.
Classic ASP
Environment assumes code and libraries are written carefully and debugged and stress tested. Flaws in codes or component or memory leaks cause system deterioration and may require soft and hard reboots.

ASP+ worker process assumes all components and code are likely to crash, leak memory and have bad code (infinite loops, forgetting to advance recordsets). The ASP+ worker process notices bad code and then isolates the thread the code is on, allows no new code to run on same thread and then destroys the thread and all bad code. If code leaks memory, ASP+ worker can create a new instance of itself to run requests and tear down the previous instance that has memory leaks without ever rebooting.
Classic ASP
No debugging tools unless Visual Interdev is editor. Debugging tools are crude and have limits on how deep they can examine the system. Error trapping in all languages has severe limits. VBscript has ON ERROR RESUME NEXT and not ON ERROR GOTO. Javacript on server has TRY/CATCH but no other language does.

Powerful debugging, millisecond timing and profiling are built-in. These can be done without GUIs. All current page requests can be logged and inspected after the fact.
Debugging can also be done with GUI tools that are not married to any editor specifically. Error trapping at code level is easy because there are many error trapping directives (about 8 x as many as Classic ASP). Most languages support TRY/CATCH and several other robust error trapping styles.

I can say these are some of main differences between these two versions of web development language, there are many that makes ASP.NET a powerful language.!! 
Comments: Post a Comment

<< Home
a blog on Technology of Microsoft & much more..

My Photo
Location: Chennai, Tamil Nadu, India
May 2004 / June 2004 / July 2004 / August 2004 / September 2004 / October 2004 / September 2005 /

Powered by Blogger