Seven Things You Need to Know about ASP.NET
Throughout the remainder of this book, you
will be presented with virtually every aspect of ASP.NET programming from form
processing to security. Before we dive into the wonderful world of ASP.NET
programming, a few short introductions are necessary. This section will outline
some key facets of this exciting new technology, and provide you with the
fundamental building blocks to get up and running. The following sections will
provide brief introductions to topics specific to ASP.NET application
development. We'll begin by examining the general constructs of the .NET
Framework and how they tie into ASP.NET, and later delve deeper into how
ASP.NET integrates within the larger picture to provide rich functionality for
your web development efforts.
ASP.NET is Integrated with the .NET Framework
A large portion of my career is spent on
mentoring up-and-coming distributed developers and colleagues who participate
in corporate development projects. One of the first things I have found that I
mention to these individuals is that their starting point for documentation
should be the .NET Framework Class Library. This section of the MSDN site, and
the documentation within the .NET Framework SDK, is the single most informative
documentation area in all of the documentation so far released.
Distributed computing is little more than the sum
of its parts. Each and every moving piece of a larger puzzle contains virtually
100% of the responsibility of system maintenance and stability, and any one
piece that is overlooked can (and usually will!) break in time. The .NET
Framework is divided into an almost painstaking collection of functional parts,
and to be ready for development in the framework, a decent understanding of
these parts – and an even greater understanding of the rationale for division –
is crucial.
The massive
collection of functionality the .NET Framework provides is stored in a fashion
many COM+ programmers will be happy to receive. Organized in a hierarchical
namespace structure, the thousands of classes in the .NET Framework offer
utilities for nearly every aspect of distributed development, from message
queuing to security. Any installation of the .NET Framework (and soon its
shared Common Language Infrastructure implementation which will provide .NET
namespaces to non-Windows developers) provides an identical namespace
structure, so deployment is relatively simple. In most cases, using XCOPY to
copy files into production is the only deployment requirement, provided the
host machine contains the .NET Framework installation.
Additionally,
any custom classes that you build can integrate quickly into the Framework
namespaces so that other team members and developers have easy access to your
functionality. In all likelihood, you may determine that an already resident
namespace needs some degree of extension via sub-namespaces. Using the
Framework, this is not only possible but painless as well. For example, your
application may require its own authentication scheme that theoretically will
be used for the sole purpose of securing web services. Using .NET, you could
create a new namespace called Security that exists as a child namespace of System.Web.Services.
Once your new namespace and any classes located within it are deployed into a
production environment, the new namespace will appear in the .NET Framework
namespace hierarchy as System.Web.Services.Security.
Web
Forms
For years, Windows
developers have had more access to systematic resources, API functionality, and
fewer security considerations than have ASP-based web developers. Simply, if
you're developing forms using Visual Basic or C++ that will eventually be
deployed to the Windows desktop, it seems an obvious likelihood that more
Windows "hooks" will be available for your development.
Again, we'll use the example of object creation.
Visual Basic developers have scoffed at the thought of late binding to controls
and objects needed by an application; ASP developers had no choice in the
matter, and were forced to go this route.
The .NET Framework removes this dynamic from the
picture entirely. Imagine a web development framework in which you had access
to every system and network resource – security, data access, data binding, and
so on – that your desktop counterparts have taken for granted for years.
The
Common Language Runtime's Role in ASP.NET
Perhaps the most
important aspect of ASP.NET to remember is that it runs inside the system
context of the Common Language Runtime, and thereby has access to every other
object that behaves similarly. The whole of the .NET Framework – that is, all
namespaces, applications, and objects that run as .NET applications – are
referred to as "managed" code. Though a full-blown investigation of
the CLR is beyond the scope of this chapter, a few primary notes are important
to make before we continue our investigation into how ASP.NET utilizes the
CLR's resources. This section will take a brief look at these key points and
discuss what how they fit into the picture.
Cross-language Integration
Underneath the CLR resides the Common Type System, or CTS. This
system provides developers willing to deploy language compilers with a series
of rules and guidelines that could theoretically result in the development of
language compilers for virtually any programming language. The CTS provides
guidelines for data type conventions, method overloading, memory pointer
specification, and any other low-level requirement for a working programming
language. If a compiler were to adhere to all rules and specifications provided
by the CTS, the resulting Interface Language code that deployed into the CLR
would be .NET-usable.
Compared to classic ASP
programming, which allowed programmers two choices – VBScript and JScript –
ASP.NET is a quantum leap in functionality. ASP.NET is so tightly integrated
with the CLR and the Framework that your ASPX pages will have all the same
functionality as your Windows Forms counterparts. To boot, if your favorite
language is unsupported by the CLR (and you have a lot of free time on your hands), you
have the option of developing a custom compiler that would enable you the
freedom to continue using that language during your .NET development efforts.
Since compilers already exist for many languages, you can write ASPX
applications in Eiffel, COBOL, PASCAL.
Structured
Error Handling
If you've ever
written any moderately useful Visual Basic or VBScript code, you'll most likely
be familiar with the limited resources for error handling these languages
offer. With structured error handling, your applications have the added benefit
of executing internal checks and balances without having to jump in and out of
subsequent error-handling routines. Your application methods can include
complex – even nested – error handling capabilities that occur as a portion of
their including method, rather than forcing the application to jump (or GOTO)
to named error handling routines.
Automatic
Memory Management and Garbage Collection
With .NET, Microsoft
has adopted a new methodology of placing objects and reference types into
memory. When managed application execution begins, a block of memory is
allocated for that application to run within by the runtime itself. A reference
is set to the address of each object that gets instantiated by the application,
and is later used to place subsequent objects in the memory process – known as
the managed
heap. In this way, the runtime places objects on
the heap as they are needed and utilized. The result is a ladder effect; managed
applications keep track of each object that is created by way of a memory
pointer to that object's location that is later used as the address of any
additional object the application might need. As objects are created, their
memory location is used to place subsequent objects upon the heap itself.
In addition to this more rapid method of
instantiation, the .NET runtime provides automatic garbage cleanup for objects that remain in memory. Since the managed
heap is utilized in a linear format, the garbage collector can quickly and
easily observe which objects still on the heap contain any inactive references.
As program execution continues, various processes complete. The garbage
collector maintains a watchful eye over each object that resides in the heap.
As process flow completes and certain objects are unneeded as a result of their
functions having been completed, the garbage
collector removes them from the heap.
As a result of this handiwork, the developers' responsibility
of cleaning up vanishes, thereby allowing you to spend more time on application
development and less time on troubleshooting complicated memory problems.
Self-describing
Metadata
Metadata is
generated when any managed application's Intermediate Language (IL) is created
during program compilation. Metadata tells the CLR more about your application
and is parsed during just-in-time (JIT) compilation where native code is
generated. This data is highly useful when you're creating components and
custom controls using assemblies.
Buy Fast Track ASP.NET here
© Copyright 2002 Wrox Press
These chapter is written by Brady Gaster, Marco Bellinaso & Kevin Hoffman
and taken from "Fast Track ASP.NET" published by Wrox Press Limited in June 2002; ISBN 1861007191; copyright © Wrox Press Limited 2002; all rights reserved.
No part of these chapters may be reproduced, stored in a retrieval system or transmitted in any form or by any means -- electronic, electrostatic, mechanical, photocopying, recording or otherwise -- without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.
|
|
