Ok, my turn.
Everything you say below is correct, but still does nothing to differentiate
code-behind/code-inside (beside).
The first half of your post talks about OO and as you say if you run as one
page the fact that it is a class is hidden from you. Why is that a problem?
I use objects all the time where the details are hidden from me, that
doesn't make them any less valuable. As a matter a fact that is one of the
positive things about objects. That you don't have to worry about all the
underlying details.
You yourself say that the page is an object, so again no difference. You
can use an object one way and I another. This does not make one use better
than another, necessarily. All of your comments about OO work for both
methodologys. The fact that I can cut the code from my Code-inside and move
it directly to a code-behind page (with a few tweeks such as reference to
each other at the top of each page) attests to that.
Objects have IDs so you can access them. But you don't have do give them
IDs. Buttons are a good example. If you aren't going to access any of the
methods or properties of the button, you don't need an ID. Doesn't make it
any less valuable or bad way to use it. Just one less name I have to come
up with.
The 2nd half of your post you are talking about VS and how MS uses it - not
about code-behind vs code-inside. The fact that MS chooses to do
code-behind only is its choice (not that it is better). You, therefore,
have no choice. You must go with MSs way of doing things (code-behind).
You mention that the pages are compiled. There really is not much advantage
in compiling (as far as I have read), other than the first time a page is
referenced when a change has been made (and that is apparently going away
with 2.0). When you compile the code you are compiling into machine code,
but into MSIL, or Microsoft Intermediate Language, is the intermediate
language all .NET applications are compiled down to. So you still have some
more compiling to do when the page is executed. Everyone (that I have
heard) says that the pages are just as fast either way - so not much benefit
there.
Now there may be some discussion between VS vs other tools but that is not
between code-behind vs code-inside. This is a matter of preference. I have
read from many that don't like VS are just chomping at the bit for 2005 - so
the VS direction is not necessarily the best way to go - but it may be.
Just another preference.
You talk about Intellisense. Again you are referring to VS not code-behind.
DW does much the same thing but not to the extent that VS does as it is not
ASP.NET centric ( I am not touting DW here, just pointing out the
similarities and differences - as a matter a fact I am looking forward to VS
2005).
When we get VS 2005, this code-behind/code-inside discussion will be less
germane. This is due to the fact that by default VS 2005 will be
code-inside, unless you tell it to use code-behind through the page
attribute (at least that is what I have heard).
And as you mention about debugging - tracing is a valuable tool (available
to both). Other debugging tools are particular to VS itself.
More below
Cowboy (Gregory A. Beamer) - MVP said:
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.
So no difference.
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.
Right. No difference.
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.
As happens with most objects. No discernable advantage here except for
code-behind as you can concentrate on building your page instead of making
sure all your imports and references are there. In most cases, they already
are - which to me is the essence of OO.
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.
Same in both cases.
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.
Same in both cases.
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,
Not really. And that is not a bad thing anyway. I don't want direct
connection with an object just to have it. I want it if it is necessary.
The fact that you don't directly call Page_PreRender doesn't mean it isn't
there. I can call it if I need to.
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.
I run the application in the browser from DW.
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.
Down to MSIL.
The code will throw compiler errors, which
you can fix before you deploy.
I get that from DW.
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.
Agreed. In both cases.
As stated above, I agree with all you statements here. They just don't make
a case for behind/inside, as far as I can see.
Alan, your turn.
Tom