|
xxx
ASP and Asp.net Differences Summarized
A SUMMARY OF CLASSIC ASP and ASP.net DIFFERENCES
Classic Asp Objects support:
- 6 objects, see:
http://www.learnasp.com/start/objects.asp
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.
Asp.net Objects Support:
-
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.
- The "guts" of the component glue and framework are not tied to INTEL or
WINDOWS. The first release is Windows but porting to other computing
environments is feasible.
-
The NGWS Framework which has ALL the facilities needed to build a ROBUST
commercial product of the scope of Office 2000. NGWS is a huge library with
thousand of objects that are self-documenting and can be programatically
interogated. They range from browser interaction to cryptography to GDI/GDI+
libraries. Sockets and Higher-Level constructs.
look at: /learn/pngmake.aspx
which
shows making a PNG, GIF, TIF, BMP file on the fly without 3rd party components for example.
The class browser at:
/quickstart/aspplus/samples/classbrowser/vb/classbrowser.aspx
demonstrates the rich object model that is available and how it can even be
programatically accessed via reflection.
Classic ASP Language Support:
-
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.
ASP.net Language Support:
-
3 built in COMPILED languages (has NO scripting languages): VB7 / VBNET, C# and
JScript / JSNET
- To blow your mind check out:
/learn/visualinheritance.aspx
which shows how graphic designers can work on one file and programmers another
SEPARATE file.
Classic ASP Database Support:
-
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.
ASP.net Database Support
Classic ASP Scalability:
-
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.
ASP.net Scalability:
- 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 see:
/learn/caching.aspx
reduces database access and code execution dramatically without
requiring page-level changes.
Classic ASP Third party support
-
Some essential COM components that are needed to build websites (browser
detection, etc.) -- Simple but useful. Most sites with complex needs will have
to build or buy many COM components to complete tasks.
ASP.net Third party support
Classic ASP Browser Support
ASP.net Browser Support
- Validators and built-in components
use detection to render GUIs that behave consistently on
a variety of browsers. ASP.net 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.
Classic ASP Execution Environment
- 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.
ASP.net Execution Environment
- 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 Deployment:
-
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. see:
/learn/config.aspx
for more details.
ASP.net Deployment:
-
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.
Classic ASP Versioning approach:
-
New versions of components required stopping and starting the server.
-
Once new component versions were deployed, old versions were replaced.
ASP.net Versioning approach:
- 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 ASP.net 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 Stability:
- 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.net Stability:
-
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.
see:
/learn/crashproof.aspx
for more info.
Classic ASP Debugging:
-
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.
ASP.net Debugging:
-
Powerful debugging, millisecond timing and profiling are built-in. These can be
done without GUIs. see:
/learn/debug2.aspx
for a sample.
- All current page requests can be logged and
inspected after the fact. see:
/trace.axd
for a live example on our server. (normally such things would be password
protected on YOUR sites so only coders could access)
- 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.
 |  |  |
|
There are many worthy charities!!. But perhaps help starving children in Africa or South America AND help Charles too.
a $5 tip buys him lunch at McDonalds,
a $20 tip buys his kid Hitoshi a new computer game,
a $39 tip buys his daughter Michiko a few nice outfits.
See our donor list.
| |
 | |  |
|
|
|
|