This may ramble a bit, as I am writing it on the fly. Hope it starts to
illuminate the concepts.
First, let's understand that .NET uses an OO methodology. What this means is
you design your objects as classes. Your tagged page is derived from your
CodeBehind, which is derived from System.Web.UI.Page. If you do not use
CodeBehind, you still derive from System.Web.UI.Page, but this fact is hidden
from you.
TO better understand OO, you have to start thinking in objects. The easiest
way to understand the concept, for me, is to think in terms of financial
markets. In the financial world, you have commodities and securities.
Commodities are actual physical items, like corn, oats, cattle. The commodity
market, ultimately, is involved with selling these items (yes, this is
getting to OO, just hold on). Securities represent real world concepts that
are not physical. When you own stock in a business, you have a security. You
cannot walk up to the physical location and take a brick, as the ownership is
an abstract concept.
Now to OO. Classes are blueprints to represent objects. When you run a
program, you make an instance (instantiate) of a class; this is an object.
The objects can be physical (like a commodity), like employees, customers,
books in inventory, etc. These are easy to identify. They can also be
abstract (like a security), like orders, processes, etc. In a fully OO
system, objects interact with objects.
Your web page, for example, contains a variety of objects, most of which are
controls. The web page, itself, is also an object.
Now, where OO pays off. When you create a new web page, there are events
that the system goes through. These events are set up in both
System.Web.UI.Page, as well as other classes in the hierarchy (ultimately
ending on System.Object). When you create a page, you can effectively ignore
most of the events, as the system is handling setting up the page for you.
The one you normally do not ignore is Page_Load, but even this is a built in
abstraction for System.Web.UI.Page.Load() (built into the compiler).
When you drag and drop controls on a page, or write the tags in your ASPX
file, you inherit all of the benefits of having the System.Web.UI.Page class
underneath. The page will parse and render HTML, as the ability is built in
underneath the hood. The page will handle events, like Page_Load and run the
code you have there (also built in to the class hierarchy). Each of the
controls will render correctly in the browser and you have a built in caching
mechanism called ViewState.
Now, try to imagine a non-OO ASP.NET world. The closest I can come to (real
world) is writing your entire application in JavaScript embedded in an HTML
page. Don't think this is real? Open a page, insert a bunch of controls with
events to handle them. Open the page in a browser and View Source. Look at
how much client side code is written for you that you simply inherit as part
of the framework.
Back to the topic of the thread. When you embed everything in the page, you
lose the direct connection to System.Web.UI.Page, as the connection is
slapped on by the ASP.NET engine to make your page work. While you still have
the inheritance, you are largely typing blind and debugging by running the
application in a browser. In addition, the tools cannot help you, as the
tools are built for a direct inheritance chain, not an implied chain (this is
getting better in the next version of Visual Studio, of course) - what I mean
here is there is no Intellisense or any other help if you need to poke down
to base class functionality. This is not a problem with simple applications,
but becomes critical as applications get more complex.
Another benefit of code behind is you can run compile on your application
rather than debug in a browser. The code will throw compiler errors, which
you can fix before you deploy. WHen you embed in the page, you end up
debugging in browser, which means you have to deploy somewhere to actually
see what is going wrong. In addition, there are no debuggers for embedded
code. At your present stage in development, you may not see this as
important. Once you get used to using debug tools, however, you will
instantly notice the increase in speed in coding and in finding errors.
By the way, one thing you should learn to use, that will save you tons of
time "debugging" a production application, is tracing (the Trace class). It
only runs when tracing is on, so it is not major overhead in a correctly
working system.
I may have confused the issue more than helped it (hope not), but my time is
up for now.
---
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************