Problems ASP.NET Solves
Microsoft has released various web application development methodologies since
the shipment of IIS in Windows. Why do developers need ASP.NET? What problems
does ASP.NET solve that the previous development methodologies did not solve?
Microsoft’s first popular web development technology was the Internet Database
Connector (IDC). The IDC methodology provided only database access; it did not
provide access to any other resource programmatically. For example, there was
no way to programmatically send email or do other non-database operations.
Another issue was that it seemed to be somewhat different from the traditional
programming languages that most developers were used to (Visual Basic and C++
being two popular ones). Along with this problem was the fact that the
development experience was not very attractive within Microsoft FrontPage.
Along with the development experience, IDC had no debugging experience worth
mentioning. Overall, IDC was nothing more than a stopgap measure to get to an
improved environment.
The next web development methodology from Microsoft was Active Server Pages
(ASP). ASP was a scripting environment that allowed developers to work with a
Visual Basic–like or JavaScript-type environment. Unfortunately, this type of
environment came with several problems:
-
Prevalence of spaghetti code — ASP code does not provide a
structured development environment, often contributing to the creation of
twisted and tangled “spaghetti code.” ASP code is literally a file with some
basic configuration information at the top of every page. Each page is executed
from the top of the page to the bottom of the page. Although it is possible to
use Component Object Model (COM) objects to eliminate some of the spaghetti
code, this introduces more complexity in the form of another development tool.
|
Book Excerpt: Introduction to ASP.NET AJAX
Chapter Contents
This excerpt from
Beginning ASP.NET 2.0 AJAX by Wallace B. McClure, Paul Glavich,
Steve C. Orr, Craig Shoemaker, Steven A. Smith, Jim Zimmerman, is printed with
permission from Wrox Publication.
|
-
Lack of code separation— The code tends to be intermixed with display code.
Intermixing the code and the display logic requires that the tools developers
and designers use work well together. This was often not the case. For example,
it was well known that various visual development tools could take a properly
running ASP page, rearrange some of the code, and render the ASP page
broken.
-
Lack of code reusability—There is very little ability to reuse code within the
ASP environment. Code reusability in classic ASP is a function of providing
logic in the form of COM objects, as opposed to something within the ASP
environment.
-
Lack of debugging support — Debugging an ASP application typically involves the
use of Response.Write. This is in sharp contrast to an integrated development
environment (IDE) developed within a GUI environment.
-
Problems of COM — ASP is based on the Component Object Model and suffers from
many of the problems associated with COM. There were two major problems with
COM:
The
first was that updating COM objects tended to overwrite one object
with
the new one. This could be problematic if a programming method
call
changed or any other new behavior was introduced.
The
second major problem with COM was that it was a binary
standard. This binary standard was based on a 32-bit programming
model.
As a result, COM objects would not scale up to run natively
within
an environment that was an Intel-based, 64-bit environment.
Although this might not have been a big deal in the early to middle
1990s
when COM was designed and built, by the early 2000s and the
introduction of inexpensive 64-bit systems, this was seen as a
possible bottleneck.
-
Problems with being interpreted—ASP is interpreted. Each time an ASP file is
loaded, the ASP environment parses the ASP file, compiles the code, and then
executes the file. This process is repeated on each call to an ASP file. The
result is wasted processing on the server.
-
Presence of the state machine—ASP applications typically have a state machine
at the top of every ASP page that processes the state of the user and then
displays code. (In software code, a state machine is a section of code that
depends on both its direct inputs and inputs made during previous calls.) Given
that most client-side applications are built based on events, which is a
similar concept to a state machine, this is an unfamiliar way to develop for
those not well versed in ASP.
After getting feedback from developers, Microsoft developed ASP.NET, which
greatly simplifies the web development methodology:
-
Developers no longer need to worry about processing state. With ASP.NET,
actions are performed within a series of events that provide state machine-like
functionality.
-
With the use of a code-behind/beside model, code is separated from display. By
separating code and display files, there is less of a chance of designer and
developer tools interfering with each other.
-
A single development tool may be used for building the application and business
logic. By having a single integrated development suite, developers are able to
more easily interact with the application logic. This results in more code
reuse and fewer errors.
-
With the Visual Studio 2005 IDE, ASP.NET supports many methods to debug and
track a running ASP.NET application.
-
Because ASP.NET is based on the common language runtime (CLR) and .NET, ASP.NET
does not suffer from the versioning problems of COM. The .NET framework allows
for multiple versions of components to be on a system without their interacting
with each other.
-
ASP.NET is compiled. The first time that a file is loaded, it is compiled and
then processed. The compiled file is then saved into a temporary directory.
Subsequent calls to the ASP.NET file are processed from the compiled file. The
execution of the compiled file on requests is faster than the interpreted
environment of classic ASP.
All in all, ASP.NET is a dramatic improvement over ASP and has become widely
accepted in the development community.
Page
1 | page
2 | page
3 |
page 4 |
page 5 |
page 6 |
page 7 |
page 8
|