Code Behind vs not

[Kevin Spencer]

I couldn't disagree with you more here.

Oh, I'll bet you could if you really tried!

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Kevin Spencer]

Hi Tom,

If you don't have the downloadable .Net SDK installed, here's a link to the
online version Section Head for Developing ASP.Net Server Controls:

http://msdn.microsoft.com/library/d...uide/html/cpcondevelopingwebformscontrols.asp

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

Hi Tom,

If you don't have the downloadable .Net SDK installed, here's a link to
the online version Section Head for Developing ASP.Net Server Controls:

http://msdn.microsoft.com/library/d...uide/html/cpcondevelopingwebformscontrols.asp

Hi Kevin,

Looks like a lot of reading for me in foreseeable future.

Thanks,

Tom

 

[Aquila Deus]

Hey, that guy, Aquila Deus... He's Sawyer, from "Lost"!!!!

(hard to understand why he tries to showcase code-behind with a site
that could be done in pure html with three javascript rollovers????)

I didn't, your silly kid. The site I gave is a showcase for XSLT. If
you read it carefully, you would find it doesn't even use any
server-side scripting.

 

[Alan Silver]

As you will see, keeping code in one file makes more sense as you move

into the 2.0 Framework

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.

 

[Kevin Spencer]

When I started programming I read a lot of books. After a number of years, I
was approached by Wrox to co-author several books. After working on several
books, and being a technical editor for several others, I can assure you
that book authors are just developers like you and me, and as prone to
opinion as anyone else. Therefore, take any book you read with a grain of
salt. Eat the meat, and spit out the bones.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Juan T. Llibre]

re:

I started reading ASP.NET 2.0 by Dino Espirito

Snippet sent to Dino *Esposito*,
who'll have a hearty chuckle, I'm sure... ;-)

 

[Alan Silver]

re:

Snippet sent to Dino *Esposito*,
who'll have a hearty chuckle, I'm sure... ;-)

As I typed it (from memory I should point out), I wondered about adding
a "spelling?" in brackets after the name and decided against it!! Looks
like I should have.

 

[Alan Silver]

When I started programming I read a lot of books. After a number of years, I

was approached by Wrox to co-author several books. After working on several
books, and being a technical editor for several others, I can assure you
that book authors are just developers like you and me, and as prone to
opinion as anyone else. Therefore, take any book you read with a grain of
salt. Eat the meat, and spit out the bones.

OK, but when someone of his experience and standing makes a statement
that seems to be contrary to the general feeling around here, it's worth
asking about.

At least it shows that the discussion has merits on both sides and is
not as clear cut as some would like to have us believe.

Ta ra

 

[Kevin Spencer]

OK, but when someone of his experience and standing makes a statement that

seems to be contrary to the general feeling around here, it's worth asking
about.

That is logical.

At least it shows that the discussion has merits on both sides and is not
as clear cut as some would like to have us believe.

That is an assumption. It doesn't necessarily show anything. There are many
reasons why the book may have stated what it stated. For example, when .Net
first came out, Visual Studio.Net wasn't ready for prime time. A number of
publishers decided to get some early money by publishing books prior to the
release of VS.Net. As a result, most of those books covered hand-coding and
Code-Beside. Does this mean that hand-coding and Code-Beside are desirable?
No, it means that hand-coding and Code-Beside were all that was available at
the time. Another reason for an author sticking to hand-coding and
Code-Beside is that the author is writing for a large audience about a
programming technololgy. Some of their audience has Visual Studio.Net. Many
do not (VS.Net is expensive). How useful is a book about a programming
technology when you don't have the tools it references? How necessary is it
to talk about using Visual Studio.Net when it is not necessary to do so,
because the compiler tools are available with the .Net platform?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Alan Silver]

At least it shows that the discussion has merits on both sides and is not

That is an assumption. It doesn't necessarily show anything. There are many
reasons why the book may have stated what it stated. For example, when .Net
first came out, Visual Studio.Net wasn't ready for prime time. A number of
publishers decided to get some early money by publishing books prior to the
release of VS.Net. As a result, most of those books covered hand-coding and
Code-Beside. Does this mean that hand-coding and Code-Beside are desirable?
No, it means that hand-coding and Code-Beside were all that was available at
the time. Another reason for an author sticking to hand-coding and
Code-Beside is that the author is writing for a large audience about a
programming technololgy. Some of their audience has Visual Studio.Net. Many
do not (VS.Net is expensive). How useful is a book about a programming
technology when you don't have the tools it references? How necessary is it
to talk about using Visual Studio.Net when it is not necessary to do so,
because the compiler tools are available with the .Net platform?

OK, the only comment I have here is that the book seems very centred
around VS.NET, which is a downer for me as I don't have it. He seems to
champion code-beside, partly because it can be done properly now in
VS.NET 2005. He has quite a go at the inadequacies of VS.NET 2003, so
I'm not sure if your comments are appropriate in this case.

Anyway, thanks for the reply.

 

[fd123456]

Sorry about the obscure reference, funny only if you watch Lost (NOT
reality-tv, by the way, but an excellent series). Sawyer is just a
character that embodies people who love to be hated. I was under the
impression that it's what Aquila was after.

I'll never try to be funny in the newsgroups again. I'll never try to
be funny in the newsgroups again. I'll never try...

Michel

 

[Kevin Spencer]

OK, the only comment I have here is that the book seems very centred

around VS.NET, which is a downer for me as I don't have it. He seems to
champion code-beside, partly because it can be done properly now in VS.NET
2005. He has quite a go at the inadequacies of VS.NET 2003, so I'm not
sure if your comments are appropriate in this case.

Of course my comment was appropriate! ;-) All I asserted was, you can't draw
any definite conclusions about the relative merits of either side of the
debate from the book. One would have to make guesses about the intentions of
the author in order to do that. The only fact is, it is a book about
programming with ASP.Net 2.0, which endeavors to teach the reader how to
write ASP.Net 2.0 applications.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Kevin Spencer]

My aplogies, Michel. I have never watched it, and made an assumption. I am
truly ashamed that I did such a thing!

Please continue to try and be funny! I know it isn't easy. I try almost
every day, to lighten things up, but it's amazing how often my efforts are
misunderstood.

--
HTH,

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

 

[Alan Silver]

I'll never try to be funny in the newsgroups again. I'll never try to

be funny in the newsgroups again. I'll never try...

Oh go on, we need the light relief around here ;-)

 

[Alan Silver]

OK, the only comment I have here is that the book seems very centred

Of course my comment was appropriate! ;-) All I asserted was, you can't draw
any definite conclusions about the relative merits of either side of the
debate from the book. One would have to make guesses about the intentions of
the author in order to do that. The only fact is, it is a book about
programming with ASP.Net 2.0, which endeavors to teach the reader how to
write ASP.Net 2.0 applications.

OK, point taken. I think we have flogged this one for all it's worth.
Let's get back to the poor jokes, I think we were on safer ground
there!!

 

[Guest]

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.

Comments inline:

II know this wasn't addressed to me, but I hope you don't mind if I
comment as I'm very interested in what you say.
NP


Please can you define what you mean by that <SNIPPED>

I mean single file per page. Apologies for the confusion.

Why is it not proper OO? The way I understand it, code-beside just
houses the scripting bits in the top of the same physical file as the
HTML. The two are still completely separate. The addition of one small
Ctrl-Z between them would result in code-behind.

Perhaps not the best choice of words, but the core concept behind my
statement is embedding everything in your tagged documents leads to an
obfuscation of your object model. This is not necessarily a bad thing, but
there is no easy way to explicitly derive from Page without a CodeBehind
file. In addition, you are hard pressed to create your own page hierarchy.

Again, I'm not sure what you mean here, please could you explain a bit
more.

Whether you embed all of your code in a single file or use two (ASPX +
CodeBehind), you are working with an object model. In the CodeBehind, the
inheritance is explicit:

public class WebForm1 : System.Web.UI.Page
{
}

When you work with a tagged page (ASPX) alone, you lose the explicitness of
the inheritance and allow the HTTP Runtime to supply inheritance for you. In
most situations, this is not a problem, but it is a factor.

Truth is that I probably wouldn't accept a large project. I like working
on my own. I am my own boss, I get to decide how the project should run,
I design and code to my own standards, and so on. There are
disadvantages, but on the whole I am much happier working like this.
I've been part of a team and I didn't like it. I like to be in control
of the whole thing and you can't do that with a large project.

And that is a decision you have to make. I just suggest that the decision is
made after weighing the factors. I have worked with .NET for about 5 years
now (PDC 2000 beta version) and have seen what can happen when one bucks the
system (not in this respect, however). From seeing plenty of bad ASP.NET, I
am leery of kludging the system.

I do disagree with some who are being far too hardcore, as one can make a
logical decision to move away from the "proper" model. I do not advise it,
but I am not about to blast someone for making a decision that makes sense to
him/her. I would just make sure the decision was one made after weighing the
risks and the rewards.


---

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

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

 

[Guest]

I prefer the code separation. I am not particularly fond of MS's decision to
marry the two in 2.0, but I can understand the reasoning. At least in 2.0,
you will benefit from the full class model when you decide to go with a
single page model.

It is best to go one way or another, although you can mix and merge easily
enough in .NET. It leads to better consistency and more maintainable
applications.

NOTE: 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. Dreamweaver, unfortunately, is not the
best tool for this (great design tool, IMO, but not the best coding tool).

---

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

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

:

 

[Guest]

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).

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.


---

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

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

 

[Guest]

I will agree that classes are not a panacea (but, there no true silver
bullets in programming -- maybe "no" is too strong). In the case of the page
I showed, I see no advantage of creating an underlying class, except to be
more explicit. As there is little value in explicit for a page that simple,
one could argue either way.

With more complex pages, however, and esp. when using Visual Studio .NET,
you gain a lot by using the CodeBehind model. As some of the advantages are
tool based, you would not see them in Dreamweaver.

For me, my fondness of explicit code is my primary driving force to follow
the CodeBehind model. That may not be as important to everyone in the
discussion.


---

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

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