Code Behind vs not

[Alan Silver]

Therefore, you can have your cake and eat it!

Actually, there's nothing clever about that.

What *is* clever is if you can eat your cake and have it!!

 

[Alan Silver]

I was answering A question. Not THE question.

OK, see if you can answer this one ...

Three men take two days to dig a hole deep enough to fill with seven
bathtubs of water. How many beans make five?

 

[Kevin Spencer]

Hi alan,

You seem to agree that there aren't any benefits.

Not at all. I consider the whole argument to be Lilliputian in nature. I
don't agree or disagree. To me, it's a meaningless question.

As an aside, I actually like calculus. I guess that's the way my mind
works. I have a PhD in Mathematics, so I'm a bit biased!!

I KNEW there was something I liked about you! ;-) For my own edification, I
just built a Mandelbrot Set Generator. Email me and I'll send you a copy. It
includes a Complex Number class, that is still in progress, but it can add,
subtract, and multiply Complex numbers (so far). In fact, my Mandelbrot
Generator doesn't use these methods; it uses simplified algebraic equations
derived from the Calculus.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Kevin Spencer]

Five?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Alan Silver]

Five?

Darn, I knew I shouldn't have used that Bumper Book Of Easy Questions in
this newsgroup!!

 

[Alan Silver]

Hi alan,

Not at all. I consider the whole argument to be Lilliputian in nature. I
don't agree or disagree. To me, it's a meaningless question.

OK, that's a better way of putting it. It was what I meant, but phrased
in a way that pleases me more ;-)

I KNEW there was something I liked about you! ;-) For my own edification, I
just built a Mandelbrot Set Generator. Email me and I'll send you a copy. It
includes a Complex Number class, that is still in progress, but it can add,
subtract, and multiply Complex numbers (so far). In fact, my Mandelbrot
Generator doesn't use these methods; it uses simplified algebraic equations
derived from the Calculus.

Sounds right up my street!! When I was at university, I wasted enormous
amounts of resources producing Mandelbrot prints on the university's
plotter. The prints were about four feet square and took most of the
night to generate.

Mind you, that was back in the days when a computer as powerful as my
outdated PC here would require a fair-sized room and air conditioning!!

I'll e-mail you privately for the program.

 

[Kevin Spencer]

Well, Alan, this app is a bit quicker, but it uses a recursive function to
resolve the Z value, and it will generate a stack overflow if you go past
about 4096 iterations. Still, at 4096 iterations, you do get some beautiful
imagery, and to create a 440X440 image (I've been testing at that size), it
can take up to about 5 minutes (at 4096 iterations). Of course, it can
generate an image of any size, up to the limit of the size of a bitmap.

You should also appreciate the coloring. It uses a custom gradient I
developed, which has no tertiary colors. It starts at RGB0,0,64 (Dark Blue)
for a single iteration, and the colors blend "warmer" as it approaches the
limit. Blue to purple to pink to red to orange to yellow to white, very
smooth. All members above the limit (in the set) are colored black by
default.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Alan Silver]

Well, Alan, this app is a bit quicker, but it uses a recursive function to

resolve the Z value, and it will generate a stack overflow if you go past
about 4096 iterations. Still, at 4096 iterations, you do get some beautiful
imagery, and to create a 440X440 image (I've been testing at that size), it
can take up to about 5 minutes (at 4096 iterations). Of course, it can
generate an image of any size, up to the limit of the size of a bitmap.

You should also appreciate the coloring. It uses a custom gradient I
developed, which has no tertiary colors. It starts at RGB0,0,64 (Dark Blue)
for a single iteration, and the colors blend "warmer" as it approaches the
limit. Blue to purple to pink to red to orange to yellow to white, very
smooth. All members above the limit (in the set) are colored black by
default.

Sounds good, I can see whole days being wasted playing with it instead
of doing some real work!!

I await the code ...

 

[Guest]

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!
***************************

 

[tshad]

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

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

 

[Alan Silver]

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.

You beat me to it!! I was about to type exactly the same as you, except
that I was going to point out that I understand OO a whole lot better
than I understand the financial world!!

I can see that the debugging is an issue, but like Tom said, that's a VS
thing, not an inherent code-behind thing. And again, VS.NET 2005 sounds
like it has that sorted out too.

Thanks to both of you for the comments.

 

[Guest]

One of the biggest benefits is to abstract away the logic of how the UI works
from the actual presentation itself (i.e. HTML, XHTML, WML, etc.). One
example where this is a huge problem is ASP/HTML - yuk!

The other big benefit is code re-use. In .NET you can have your pages
templated so that each page inherits its visual implementation from a single
"master page". If you ever have to change the appearance, you just change
the master page, not all 30 pages or whatever your site might have. Let's
say you have a common UI validation method that is used by all of your pages,
if you don't use the code-behind concept, you'll be stuck doing something
*stupid* like using include files - or worse yet, copying this method into
every page that uses it. Can you say maintenance nightmare?

If you know anything about OO, you'll realize the benefits right away.

Dave

 

[Matt Berther]

Hello Dave,

Codebehind should not be mistaken for having classes. If you have a common
validation method, perhaps the codebehind is not the right spot for it, but
rather a ValidationHelper class.

This class can be accessed from either the code-behind or inline.

Don't get me wrong, I absolutely prefer code-behind. I just want to make
sure that people are aware that you can still realize the benefits of OOP
without using it.

 

[tshad]

Hello Dave,

Codebehind should not be mistaken for having classes. If you have a common
validation method, perhaps the codebehind is not the right spot for it,
but rather a ValidationHelper class.

This class can be accessed from either the code-behind or inline.

Don't get me wrong, I absolutely prefer code-behind. I just want to make
sure that people are aware that you can still realize the benefits of OOP
without using it.

Here, here Matt.

This is the point we have been trying to make for awhile in the quest for
opinions on behind vs inside.

We all see benefits of OO. I haven't heard anyone say anything against
that.

The problem was in differentiating the discussion between the two.

Tom

 

[Juan T. Llibre]

re:

If you know anything about OO,
you'll realize the benefits right away.

Are you talking to me ?

I was pointing out that the argument has been
deliberated to exhaustion, not only in this thread
but in other threads.




Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

 

[Alan Silver]

I was pointing out that the argument has been deliberated to

exhaustion, not only in this thread but in other threads.

Not that this point will stop us from continuing to debate it for many
days to come ;-)

We may even get into the Usenet book of records for the longest and most
boring thread ever!!

 

[tshad]

Not that this point will stop us from continuing to debate it for many
days to come ;-)

A little debate is good for the soul

Of course, if a little debate is good for the soul, what's a lot of debate
good for?

Tom

 

[Alan Silver]

I was pointing out that the argument has been deliberated to exhaustion,

A little debate is good for the soul

Of course, if a little debate is good for the soul, what's a lot of
debate good for?

Filling up the day, whilst avoiding doing any real work!!

 

[tshad]

Filling up the day, whilst avoiding doing any real work!!

I wouldn't say - "not doing any real work"

What about the benefit you get from mental stimulation?

Tom

 

[Alan Silver]

Of course, if a little debate is good for the soul, what's a lot of debate

I wouldn't say - "not doing any real work"

What about the benefit you get from mental stimulation?

Well, it keep me awake I suppose, but then if I wasn't doing this, I
could just as well go to sleep anyway as I'm not actually doing any
work!!