Code Behind vs not

[Guest]

CodeBehind looks like this (UML like model)

----------------------------
| System.Web.UI.Page |
----------------------------
^
|
----------------------------
| YourPage.Aspx.cs |
----------------------------
^
|
----------------------------
| YourPage.Aspx |
----------------------------

2.0 is more like this

----------------------------
| System.Web.UI.Page |
----------------------------
^
|
----------------------------------
| YourPage.Aspx.cs - partial |
| YourPage.Aspx - partial |
----------------------------------

Both are required to create a single class, instead of inheriting from the
CodeBehind. Functionally, it works the same way, but it simplifies the
runtime significantly and makes it easier for the person using ASPX alone to
code a class that is more easily recognized as a class. There are some
minuses, under the hood, to the model, as well, but that is a topic for a
more involved thread.

The CodeBeside model allows you to separate your information as you see fit.
While I would not do it, it is possible to do the following:

MyPage.aspx - tags
MyPage.aspx.cs - events from the tags
MyPage.helperFunctions.cs - internal methods used by the events.
....
ad nauseum

All of the partial classes can be compiled together and still only end up
with one class and therefore only one object in memory (for your code, as the
Page object, etc., will still be loaded).

Not sure if that makes sense. For the short answer: CodeBeside is better OO
(more efficient as well as a better object model).

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Aquila Deus]

I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0 by
Dino Espirito last night. Right at the start of the book he appears to
say that code-behind isn't all it's cracked up to be, and that
code-beside is functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was
arguing reasonably strongly in favour of code-beside. I'm not sure if

I'm right, as a couple of the comments he made didn't quite fit with how
I understand code-beside (and also because the book so far is heavily

weighted towards VS.NET users, which I'm not yet), but maybe if someone
here has the book they could clarify this.

Obviously he doesn't like MVC, that's too bad!

 

[Alan Silver]

Not sure if that makes sense.

Not too much!! I must confess to being more than a little confused with
this whole subject now. I'm really not quite sure how the whole class
thing works in ASP.NET. I get the idea of classes you create explicitly
in your code, and classes in the .NET framework that you use, but I
haven't worked out quite what the idea of the page itself being a class
really means.

Perhaps I'm trying to run before I can walk. I think I have a pretty
good grasp of most of the concepts behind ASP.NET, but this one is still
beyond me.

Any simple explanations would be welcome!!

 

[Alan Silver]

Over-engineering can certainly be a problem. Many people, however, think over

is more common than under, when the opposite is generally true (as seen by
the many ASP.NET error pages you hit on the web :-0).

Oh, and I thought it was just me that noticed those!!

What amazes me is the lack of error checking. It's so easy to catch an
error and just display something else instead of an ASP error message
half way through a crashed page.

It sounds like you have thought the whole thing through. I would still argue
for the two file methodology (ie, CodeBehind), but you can always move to
that model later, if it makes sense to you. Refactoring is a part of life.

I'm trying to think it through!! Getting confused, but trying.

At the moment I am coding completely by hand, partly because I feel I
will learn more that way, and partly because I see little point in
buying VS.NET (not cheap) at a stage when a radically new version is on
the horizon. Maybe when I get VS.NET 2005, I will revisit the concept.
Right now it seems like more effort than it's worth.

ta ra

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[tshad]

Hey Alan,

I just started reading that one myself and found that he is neither in favor
nor against code-behind. He is taking the same position some of us have
taken. That is that it is not the panacea some try to make it. His
complaint is the way MS has implemented it in VS (which is what I have said
as have others). They implement it differently in 2005. I like what he has
said about it and think I will wait until VS 2005 to start using it.

Here are some of the things that VS does that he doesn't like:

1)Single model only (even though asp.net is not)
2)Takes the project approach only
3)Requires Front Page Extensions
4)Doesn't support FTP
5)Doesn't support local file system
6)Doesn't have direct IIS access
7)Can't open single page outside of project and get Intellisense to work.

Plus others.

VS 2005 (according to Esposito) addresses all these shortcomings.

I have heard some of these problems (and others) from others that use VS
and, although I know that no tool is perfect, there is enough to get me to
switch. Especially if there is a better tool just over the next hill which
might make my transition easier.

Also, he differentiates code-behind and code-beside is in essence the same
and in-line as one page. Code-beside is just a different implementation of
code-behind.

VS 2005 will do in-line by default and only when you tell it to use
code-beside will it split the file - hardly unprofessional as some have
called it.

I think this model will better allow a Programmer to use both VS and DW or
any other tool they like. Which is one of the benefits of getting away from
Legacy code where in the old days you had no choices. Now you have choices
and can intermix your tools. VS 2005 didn't lend itself to that - as far as
I can see.

I personally am looking forward to u sing VS 2005, myself.

Obviously he doesn't like MVC, that's too bad!

Not the case. He has a problem with MVC 2003 and is thrilled with VS 2005.

Tom

 

[Kevin Spencer]

Hi Alan,

this whole subject now. I'm really not quite sure how the whole class
thing works in ASP.NET. I get the idea of classes you create explicitly in
your code, and classes in the .NET framework that you use, but I haven't
worked out quite what the idea of the page itself being a class really
means.

A class is a data type that contains both process and data. It helps if you
understand data types. The reason for data types is that in the computer,
it's all just bits. The hard drive is just a long "array" (if you will) of
bits. Memory is just streams (or, rather A stream) of bits. Now, for
example, and integer is 32 bits in length. This tells the computer to read
32 bits and the binary number resulting from that is an integer. A string is
an array of 16-bit Unicode characters terminated with a null 0 byte. The
length of the string tells the computer how many bits to read. If the string
is 8 characters long, the computer reads 16 bytes, and reads each character
by reading the 16 bits (2 bytes) of that array of bytes which is positioned
where the character is.

No doubt you're familiar with numbers and strings. But there are also
aggregate types (in fact, string is an aggregate of characters, and any
array is an aggregate). An aggregate type is a type that combines more than
one element of data into a single data type. For example, a Point is
composed of 2 integers (x and y). A Point is what is referred to as a
structure. A structure is an aggregate data type that contains more than one
type of data, or more than one data member. A structure can also contain
process (functions and subs). The size of the structure is the combined size
of all the data it holds. So, a structure is the first data type that
contains both process and data.

From structures, classes were derived. Classes are OOP, and have the
qualities of Abstraction, Encapsulation, Polymorphism, and Inheritance.
Other than that, they are much like structures.

Now, in .Net, everything is a class. A System.Web.UI.Page, for example,
consists of all the data and process needed to process an HTTP request and
return a response to the client browser. The code you write, template and/or
CodeBehind, is compiled into a class either at run-time, or, if you have a
compiler, it can be compiled at design-time. Note, however, that the class
is what actually does the work, NOT the page you see in Visual Studio. A
file is a static document. Only executable code can execute.

At run-time, the Page class reads the template, converts all the objects in
it into instances of classes, and uses those classes to return the response
to the client.

--
HTH,

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

 

[Alan Silver]

For the record, I am not, as some are, arguing that one should not move to a

model where all of the code and tags are in a single page, but you that one
should realize the consequences of the decision.

Thanks for that. Your comments are very welcome for that reason if no
other. I am trying to learn, some people seem only interested in
arguing, not discussing.

Having read your comments below, I think the main reason why I am not
seeing any advantage to code-behind is because (as mentioned in another
reply), I don't yet understand the concept of the page as a class. You
mention this a couple of time below. What is the advantage of explicitly
deriving your page from System.Web.UI.Page? You mention this a couple of
times below, and it seems to be a basic point in your argument for
code-behind. Maybe if I can get to the bottom of that, I would
understand the benefits a bit more. As I said earlier, it looks to me at
the moment as if code-behind adds coding complexity without any
advantage. You have mentioned an advantage, but I don't understand the
benefit.

Thanks for the replies

 

[Alan Silver]

Hey Alan,

I just started reading that one myself and found that he is neither in favor
nor against code-behind. He is taking the same position some of us have
taken. That is that it is not the panacea some try to make it.

That's what it seemed to me, but some round here disagree ;-)

Also, he differentiates code-behind and code-beside is in essence the same
and in-line as one page. Code-beside is just a different implementation of
code-behind.

Which is basically what Gregory was saying. He said that code-behind
makes explicit what code-beside does implicitly (if I understood
correctly, sorry Gregory if I misquoted you). The point that I'm trying
to clear up now is what difference it makes.

I personally am looking forward to u sing VS 2005, myself.

Me too.

ta ra

 

[Alan Silver]

Code separation also makes it easier to spot repetitive code, which

makes refactoring easier. It is easier to move common functionality to
a set of reusable classes or even libraries.

Isn't that just an application of common sense? Surely anyone with an
ounce of sense will be able to spot when he/she is rewriting code? I'm
not talking about poor programmers, whatever tool or methodology you
give them, they will find interesting ways to misuse it, I'm talking
about people who are genuinely interested in coding efficiently. That
sort of person would move common code into modules in any framework,
even good(?) old CGI!! Code-behind isn't going to make much difference
there, except in the specialised cases mentioned earlier, like multiple
language versions of the same page.

Ta ra

 

[Alan Silver]

Hi Alan,

Hello,

Thanks for the reply, but I think maybe I didn't make myself clear
enough. I understand about what classes are, my confusion is in why
having a page as an explicitly declared class is an advantage.

As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the
data and methods into one object. My question is, given that the page is
really the top level object that you see in ASP.NET, what advantage do
you have if you explicitly create that class, or the runtime creates it
implicitly from your coding? Either way you end up with a class which
you don't really use. Your code is inside the class and works on objects
further down the hierarchy. Who care how the parent object was created?

I hope this clarifies my question. Thanks for the speedy response.

 

[tshad]

Thanks for that. Your comments are very welcome for that reason if no
other. I am trying to learn, some people seem only interested in arguing,
not discussing.

Having read your comments below, I think the main reason why I am not
seeing any advantage to code-behind is because (as mentioned in another
reply), I don't yet understand the concept of the page as a class. You
mention this a couple of time below. What is the advantage of explicitly
deriving your page from System.Web.UI.Page? You mention this a couple of
times below, and it seems to be a basic point in your argument for
code-behind. Maybe if I can get to the bottom of that, I would understand
the benefits a bit more. As I said earlier, it looks to me at the moment
as if code-behind adds coding complexity without any advantage. You have
mentioned an advantage, but I don't understand the benefit.

As far as I can figure out, the page is a class whether it is one page or
two. You just have to explicitely tell it that it is derived from the page
class in code behind. This is done for you.

I don't see the advantage here.

As I mentioned, a couple of posts down, I had read the same book you did and
found even MS is taking the single page approach as default - as is their
examples code.

This is, again, not to say that Single page (in-line) is the best approach.
But a good approach in some situations.

I think it is a good idea to look at both approaches and use what is
appropriate for the situation.

Tom

 

[tshad]

Oh, and I thought it was just me that noticed those!!

What amazes me is the lack of error checking. It's so easy to catch an
error and just display something else instead of an ASP error message half
way through a crashed page.


I'm trying to think it through!! Getting confused, but trying.

At the moment I am coding completely by hand, partly because I feel I will
learn more that way, and partly because I see little point in buying
VS.NET (not cheap) at a stage when a radically new version is on the
horizon. Maybe when I get VS.NET 2005, I will revisit the concept. Right
now it seems like more effort than it's worth.

Actually, one reason to use VS might be to create a general purpose class to
put those routines that are used on many pages.

But I myself am probably going to wait until 2005 to do any serious
code-beside style. It appears to be a better approach that 2003 (but I
could be wrong).

Tom

 

[tshad]

Isn't that just an application of common sense? Surely anyone with an
ounce of sense will be able to spot when he/she is rewriting code? I'm not
talking about poor programmers, whatever tool or methodology you give
them, they will find interesting ways to misuse it, I'm talking about
people who are genuinely interested in coding efficiently. That sort of
person would move common code into modules in any framework, even good(?)
old CGI!! Code-behind isn't going to make much difference there, except in
the specialised cases mentioned earlier, like multiple language versions
of the same page.

This seems to be the biggest problem here. Mixing and matching questions.

This is not a code-behind question. Code separation is done in code-inside
also. It is not any easier to spot repetitive code in code-behind than in
code-inside. This might be the case were we comparing asp.net and asp.

Tom

 

[Alan Silver]

Actually, one reason to use VS might be to create a general purpose

class to put those routines that are used on many pages.

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

 

[Alan Silver]

As far as I can figure out, the page is a class whether it is one page

or two. You just have to explicitely tell it that it is derived from
the page class in code behind. This is done for you.

I don't see the advantage here.

Oh, so it's not just me!! I do feel better ;-)

As I mentioned, a couple of posts down, I had read the same book you
did and found even MS is taking the single page approach as default -
as is their examples code.

This is, again, not to say that Single page (in-line) is the best
approach. But a good approach in some situations.

I think it is a good idea to look at both approaches and use what is
appropriate for the situation.

Ah, but if there isn't any advantage to explicitly creating the page as
a class, then what is the advantage of code-behind at all?

I'm not saying there aren't any advantages, just that I have yet to work
out what they are ;-)

ta ra

 

[Alan Silver]

Code separation also makes it easier to spot repetitive code, which

This seems to be the biggest problem here. Mixing and matching questions.

Yup, I spotted that. I think it's help up this thread quite a few times.

This is not a code-behind question. Code separation is done in code-inside
also. It is not any easier to spot repetitive code in code-behind than in
code-inside. This might be the case were we comparing asp.net and asp.

Well, even in classic ASP you could easily move common functions out to
an include file, but I agree it's much neater in ASP.NET.

Which brings us back to the same question again, what *is* the advantage
of code-behind?

 

[tshad]

Oh, so it's not just me!! I do feel better ;-)


Ah, but if there isn't any advantage to explicitly creating the page as a
class, then what is the advantage of code-behind at all?

I'm not saying there aren't any advantages, just that I have yet to work
out what they are ;-)

I agree.

The problem here as the discussion keeps leaving the code-behind/code-inside
question which makes it difficult to see the advantages.

One advantage is that you can work on the same page (set of pages) with 2
people (1 design and 1 code). I don't really see this unless you go through
a lot of setting up a way to translating the asp.net objects into something
a designer understands (skins, I guess or special objects), but now you have
added a layer of complexity that the designer has to learn anyway.

I see this as a bit awkward also, since you can't just create objects on a
page without letting the other person know about it or the pages won't work
(you will get errors saying objects don't exist). This would be a problem
regardless of which style you use. You still have to coordinate when each
person can modify a page.

Tom

 

[tshad]

Yup, I spotted that. I think it's help up this thread quite a few times.


Well, even in classic ASP you could easily move common functions out to an
include file, but I agree it's much neater in ASP.NET.

Which brings us back to the same question again, what *is* the advantage
of code-behind?

The advantage is you have to do it in VS 2003

Tom

 

[tshad]

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

Tom

 

[Alan Silver]

Actually, one reason to use VS might be to create a general purpose class

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

No, the SDK comes with compilers, vbc for VB.NET and csc for C#.