Code Behind vs not

[tshad]

I didn't miss any point. Do you know the average length of time it takes
to develop a habit? 6 weeks. So, assuming that you've been working with
ASP.Net for more than 6 weeks, you've already developed some habits. Now,
let's say you graduate from working on tiny applications to something of
some size and scope. It will take you another 6 weeks to teach yourself to
do it right.

You're assuming that code-beside is a bad habit.

Based on your last post, I think you are mixing arguments OOP is not
Code-behind. You called it an extension. I don't agree here. It would
take you a little while, as you correctly state, to learn new methods. OOP
will take a while to learn. But the difference between Code-Behind vs
Code-Beside is minimal, at least as far as I can fathom (and I could be
wrong here). Based on what I have seen, you can take a Code-Beside page -
take out the script section move it to another page - add some attributes to
the Page definition - On the code-behind page add the Namespace and Class as
well as a few imports that the aspx page takes for granted as well as the
defining the objects on the aspx page (I am getting tired just thinking
about it).

Any code you want to reuse you would put in a class (which you could do -
and should do - in either case).

I don't see a bad habit here.

Earlier it was mentioned:

"Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture"

I don't agree here, either. I think the largest benefits of the dotNET
architecture is the *separation* of code from design elements (which you
didn't have in asp). A code-beside page does have the separation
(completely) from the design. It just happens to be on the same page.

I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.

I have been doing it for many more years than that (so I probably do have
some bad habits). More work in the short run does NOT always lead to less
work in the long run.

My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.

Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll
never be without a good-paying job.

Whether you use Code-behind vs Code-beside doesn't make a good programmer.
A good programmer, I guarentee you, can go from Code-beside to Code-behind
in no time at all. That doesn't mean he should.

Tom

 

[Kevin Spencer]

You're assuming that code-beside is a bad habit.

Not at all. I'm arguing that poor code organization is a bad habit. An
assumption is made without evidence. An argument, on the other hand,
provides evidence.

Also, note that I never made a specific argument about "Code-Behind." To
quote my earlier post:

It's really the wrong question. It's not a matter of "Code-Behind" versus
"Code-Beside." It's a matter of code organization in general.

You're presuming, however that that is the issue I was discussing, and had
made assumptions about. The concept of organizing code is much broader, but
does apply to specific issues. I side-stepped the specific issue, as it is
merely a symptom of the bigger (deeper) issue. Whenever I encounter a
specific issue, I tend to step back and have a look at the forest, to see if
there is a broad principle that needs to be applied overall. Once the broad
issue of code organization is identified and understood, it can be applied
specifically to all areas of development.

--
HTH,

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

 

[Alan Silver]

Alan Silver

This has nothing to do with Alan Silver. Oh darn. It has his name it
it.

;-)

You would be amazed what I get the blame for!! Even things without my
name on. If my name is on, then I'm *really8 in trouble!!

 

[Alan Silver]

I think he slightly misses the point, as you were mentioning, that it is

I didn't miss any point. Do you know the average length of time it takes to
develop a habit? 6 weeks. So, assuming that you've been working with ASP.Net
for more than 6 weeks, you've already developed some habits. Now, let's say
you graduate from working on tiny applications to something of some size and
scope. It will take you another 6 weeks to teach yourself to do it right.

Well, each of us is different, so I guess we can happily agree to have
different ideas on this, but I have more than one behaviour pattern and
can change from one to the other depending on the situation.

This doesn't just apply to programming, it applies to being a father,
running a voluntary organisation, almost anything in life. I have
behaviour patterns suited to different situations. In the case of web
programming, I have ASP behaviour patterns that I apply for small sites,
and ones I apply for larger sites. I use whichever is appropriate. I
rarely get it wrong nowadays, and rarely (almost never) waste any time
with short-term conveniences that lead to long-term problems.

I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.

You are of course entitled to your experience and your opinion, as long
as you accept them for the subjective points that they are. I have been
programming for over 20 years (yup, I'm that old!!), and have learnt how
to distinguish between a small job and one that may grow. I can't
remember the last time I got that wrong. I apply the behaviour pattern
that suits best.

My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.

Correct. But developing best practices does *not* mean applying one
mindset to every situation, it means being flexible enough to know what
to do in any situation.

Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll never
be without a good-paying job.

Well, I think the current IT slump might prove you wrong, there are
plenty of good programmers who can't get jobs, not because they aren't
good, but because there aren't always enough jobs, and managers are
being convinced that anyone can program. They are shown slick
presentations where someone creates an apparently complex application
from scratch in about ten minutes using the latest Visual Studio RAD
tools. They go away believing that a student fresh out of college can do
the same job as a highly trained and experienced professional with 20
years' experience. That's bad for everyone.

Ta ra

 

[tshad]

Not at all. I'm arguing that poor code organization is a bad habit. An
assumption is made without evidence. An argument, on the other hand,
provides evidence.

I agree.

But the fact that you use Code-beside, doesn't mean your code is poorly
organized. Alan made this point very well.

This is not to say that I disagree with using Code-Behind, because I don't.

Also, note that I never made a specific argument about "Code-Behind." To
quote my earlier post:

But this was the whole discussion. The benefits of one over the other.
Putting the code in a separate file (physically separated) or in the same
file (where it is logically separated) does not make it more organized.
Reuse of code would not necessarily be in your Code-Behind, anyway, but
could be in a different class.

You're presuming, however that that is the issue I was discussing, and had
made assumptions about. The concept of organizing code is much broader,
but does apply to specific issues.

I agree here.

I side-stepped the specific issue, as it is merely a symptom of the bigger
(deeper) issue. Whenever I encounter a specific issue, I tend to step back
and have a look at the forest, to see if there is a broad principle that
needs to be applied overall. Once the broad issue of code organization is
identified and understood, it can be applied specifically to all areas of
development.

But then you miss the point of the question when you do this. If I want the
parameters of a particular call, I don't want to know bigger issue.

I never disagreed with your points, only that it was the only way or the
best way in *all* situations.

Tom

 

[tshad]

Well, each of us is different, so I guess we can happily agree to have
different ideas on this, but I have more than one behaviour pattern and
can change from one to the other depending on the situation.

This doesn't just apply to programming, it applies to being a father,
running a voluntary organisation, almost anything in life. I have
behaviour patterns suited to different situations. In the case of web
programming, I have ASP behaviour patterns that I apply for small sites,
and ones I apply for larger sites. I use whichever is appropriate. I
rarely get it wrong nowadays, and rarely (almost never) waste any time
with short-term conveniences that lead to long-term problems.


You are of course entitled to your experience and your opinion, as long as
you accept them for the subjective points that they are. I have been
programming for over 20 years (yup, I'm that old!!), and have learnt how
to distinguish between a small job and one that may grow. I can't remember
the last time I got that wrong. I apply the behaviour pattern that suits
best.

Me too. Hard to believe, sometimes.

Correct. But developing best practices does *not* mean applying one
mindset to every situation, it means being flexible enough to know what to
do in any situation.


Well, I think the current IT slump might prove you wrong, there are plenty
of good programmers who can't get jobs, not because they aren't good, but
because there aren't always enough jobs, and managers are being convinced
that anyone can program. They are shown slick presentations where someone
creates an apparently complex application from scratch in about ten
minutes using the latest Visual Studio RAD tools. They go away believing
that a student fresh out of college can do the same job as a highly
trained and experienced professional with 20 years' experience. That's bad
for everyone.

I can tell you from experience that this is the case.

Tom

 

[Kevin Spencer]

Understood, Alan. I wasn't specifically trying to tell you what to do. I was
posting for the benefit of everyone who reads the thread. Of course, each of
us must make their own decisions regarding what is best.

Well, I think the current IT slump might prove you wrong, there are plenty
of good programmers who can't get jobs, not because they aren't good, but
because there aren't always enough jobs, and managers are being convinced
that anyone can program. They are shown slick presentations where someone
creates an apparently complex application from scratch in about ten
minutes using the latest Visual Studio RAD tools. They go away believing
that a student fresh out of college can do the same job as a highly
trained and experienced professional with 20 years' experience. That's bad
for everyone.

I do have to disagree with this point. Managers, like programmers, are a
dime a dozen. Good managers are rare. But the good managers know how to find
and hire the good programmers! ;-) I, for one, have never had trouble
finding work. I did have to give up my independent consulting business when
the DotCom crash broke out, but I've had several good jobs since then, and
more offers than I care to have to deal with.

As my old Drill Sergeant taught me many years ago: The maximum effective
range of an excuse is 0 meters.

--
HTH,

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

 

[Alan Silver]

Good managers are rare. But the good managers know how to find and hire

the good programmers! ;-)

You've just disproved your own argument. Good managers are rare,
therefore the number of managers hiring good programmers are rare. So
the good programmers don't necessarily get the jobs.

 

[Kevin Spencer]

You've just disproved your own argument. Good managers are rare, therefore

the number of managers hiring good programmers are rare. So the good
programmers don't necessarily get the jobs.

You didn't read carefully. I said that the good managers know how to find
and hire the good programmers. Since both good programmers and good managers
are rare, the number of each is such that neither good managers go wanting
for good programmers, nor do good programmers have a hard time finding jobs.
And I backed it up with my own experience.

A programmer is a problem-solver. Lack of employment is a problem. Good
programmers, who are by nature good problem-solvers, approach the issue as a
problem and solve it. Average programmers look at what everyone else is
doing, and try that.

--
HTH,

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

 

[Guest]

My recommendation is that if your application isn't very complicated, to
simply put all your code behind into a single file. Multiple classes can
exist within the same codebehind file and it makes for one central location
where you can go to modify all logic for your entire application.

I've developed many small apps in dreamweaver using this method and find it
quite streamlined. Less files to edit, less files to upload, etc.

 

[Guest]

If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.

The best code is both readable and maintainable and balances efficency.
Why? Because truly efficent code in NEVER readable, and NEVER maintainable.

True efficiency comes from breaking rules, and the code is ALWAYS ugly and
you can only maintain the code only if you truely understand it. True
understanding is a result of readability. If you had to read the code to
understand it, and understand the code to read it, you've got a catch22 that
most people will never get past.

Besides which, you are writing code for a stack based machine without
registers which will ultimately be compiled to SOME hardware SOMEWHERE with
or without registers, using SOME sort of optomization. It is impossible to
reach the true ideal of "efficent" code with that many levels of abstraction
in the way.

Shoot for reasonable efficency and make your code both readable and
maintainable, because you ALWAYS end up having to work on code again 3 years
after you though you'd never see it again (or worse, someone else). And
frankly, spending copious amounts of time trying to read code to figure out
what it does and how to modify it without breaking everything is decidedly
inefficent.

That said, inline code is good for single page projects where very simple
operations are being performed (I even have 1 page designed like that, it
contains about 3 lines of code, hardly worth code behind!). However, inline
code is horribly inefficient when dealing with a project that contains more
than 3 pages which interact (and even if you don't think you are making
objects, think again, each page is an object).

I think, however, we need to discuss your use of tools. I believe you
mentioned you were using Dreamweaver. I suspect that you will find that
OTHER tools, such as Visual Studio are significantly more efficent when it
comes to working with ASP.NET pages (you will also find tools from other
vendors such as borland, so you are not restricted just to MS, but even as a
long time delphi programmer, I prefer VS to borland in this arena).

If you would like to see how a larger scale project works with code behind,
check out dotnetnuke (www.dotnetnuke.com), and just imagine how unbelievably
hard it would be to manage the project with inline code (esp. since they've
abstracted commonly used code into objects with no associated pages).

Hope that helps.

 

[Kevin Spencer]

Very good points all, Xepol. I was particularly impressed with the
discussion of compromise in programming, which is a rather advanced but
important idea to embrace. Once you have a good grasp of the tools, it is
important to remember that code efficiency is not the only goal to shoot
for. A few cycles here and there don't make a lot of difference with
computing power at its present level, but code readability and
maintainability are certainly high priority, as programmer man/hours are
expensive.

--
Kudos,

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

 

[tshad]

The best code is both readable and maintainable and balances efficency.
Why? Because truly efficent code in NEVER readable, and NEVER
maintainable.

True efficiency comes from breaking rules, and the code is ALWAYS ugly and
you can only maintain the code only if you truely understand it. True
understanding is a result of readability. If you had to read the code to
understand it, and understand the code to read it, you've got a catch22
that
most people will never get past.

Besides which, you are writing code for a stack based machine without
registers which will ultimately be compiled to SOME hardware SOMEWHERE
with
or without registers, using SOME sort of optomization. It is impossible
to
reach the true ideal of "efficent" code with that many levels of
abstraction
in the way.

Shoot for reasonable efficency and make your code both readable and
maintainable, because you ALWAYS end up having to work on code again 3
years
after you though you'd never see it again (or worse, someone else). And
frankly, spending copious amounts of time trying to read code to figure
out
what it does and how to modify it without breaking everything is decidedly
inefficent.

I agree with all you have said. But this would be the case whether the code
is on the same page or another. You can write terrible code with
code-behind just as easily.

That said, inline code is good for single page projects where very simple
operations are being performed (I even have 1 page designed like that, it
contains about 3 lines of code, hardly worth code behind!).

This is all I have been saying.

There are times where Code-behind isn't necessarily the best way. The
problem is that people tend to feel their way is the only way. You do have
to look at the situation ( as you just stated, in essence). I have never
said anything bad about code-behind.

However, inline code is horribly inefficient when dealing with a project
that contains more
than 3 pages which interact (and even if you don't think you are making
objects, think again, each page is an object).

I don't necessarily see that, since inline (code-inside/code-beside) is the
identical code. So far everyone has said that it doesn't run any faster.
And if each page is an object, so is the code behind page for that object (I
would assume). It is specific to that page. If you have another object
that has your general routines, this is not really code-behind but a library
of classes that your pages call - which is more efficient than recreating
the same code on multiple pages.

I think, however, we need to discuss your use of tools. I believe you
mentioned you were using Dreamweaver. I suspect that you will find that
OTHER tools, such as Visual Studio are significantly more efficent when it
comes to working with ASP.NET pages (you will also find tools from other
vendors such as borland, so you are not restricted just to MS, but even as
a
long time delphi programmer, I prefer VS to borland in this arena).

That may be the case, although there are problems with VS (as there is with
any tool) according to some. The new version (2005) is supposed to be much
better. I happen to like DW and it works great for me. However, I find
that I will be using VS also (as well as code-behind) for my projects.

If you would like to see how a larger scale project works with code
behind,
check out dotnetnuke (www.dotnetnuke.com), and just imagine how
unbelievably
hard it would be to manage the project with inline code (esp. since
they've
abstracted commonly used code into objects with no associated pages).

Hope that helps.

It does.

Thanks,

Tom

 

[tshad]

Very good points all, Xepol. I was particularly impressed with the
discussion of compromise in programming, which is a rather advanced but
important idea to embrace. Once you have a good grasp of the tools, it is
important to remember that code efficiency is not the only goal to shoot
for. A few cycles here and there don't make a lot of difference with
computing power at its present level, but code readability and
maintainability are certainly high priority, as programmer man/hours are
expensive.

I agree.

Tom

 

[Guest]

This discussion seems to have focused mostly on complexity and coding styles,
and missed one of the key benefits of code behind.

When you use code behind, all of the classes that are created for your pages
are compiled into a single assembly which effectively becomes the executable
for your web app. Once the app is started, the assembly is loaded and all
classes are available as presentation service components for the pages. They
never need to be recompiled in the production environment

In contrast to this, when you use an inline coding style each page has to be
compiled on the fly on it's first request. The compiled page is then cached
so it is faster for subsequent requests, however my observations show that
even though the compiled page assembly is still on disk after a restart of
IIS or the computer, it appears to be invalidated and is re-compiled on first
request again.

The only advantage I have seen for inline coding is that you can post to
another page, which has proven useful when using online payment systems that
require you to post to a form or cgi script on the vendor site. This is
changing in ASP.NET 2.0 so then there will be no need to use the inline style
at all.

Every thing I have read, and conversations I have had with MSFT contacts
involved in developing ASP.NET suggest that the only reason the inline coding
style is available at all is to ease the transition for the thousands of ASP
developers who never really learned how to program.

 

[Kevin Spencer]

Good point, Mike!

--

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

 

[Guest]

Two more points to consider:
1. When inline code is deployed to a production server you now have server
side source code in plain text on a production server. If the server is
compromised the code now becomes visible.

2. If you have an error during compile time it will occur on the production
server. At least with code behind the compile time error will occur on your
development machine.

John Stemper

 

[Guest]

Hello all,

The arguement for Code Behind is simple.

If you need your page to render in English and you need your page to also
render in Japanese, Hebrew, and others, then you need some mechanism to
isolate the actual program code and business logic from the presentation of
the pages.

With ASP and PHP, you traditionally had to do a lot of work in order to
achieve this separation, you had to implement templating systems, etc. And
most of the common techniques -- replacement strings, etc. -- made user
interfaces look kludgey and unrefined on many foreign systems.

With code behind, you can have a separate presentation file for each
language that you support. That presentation file can be edited by standard
web tools by a web design specialist who may have no programming knowledge at
all, who may understand only (X)HTML. The fields and prompts, button layout,
etc. can all be set up however it is desired for the target language.
However they need for it to be set up.

A typical "real" ASP.NET application also will have classes that aren't part
of the user interface. In the real world, giving your web server that is
exposed to the public internet direct access to your SQL Server is a serious
security risk, one that can be exploited to gain access to information you
may not want attackers to have access to (such as credit card numbers, e-mail
addresses, etc.)

Also, if your application is complicated enough to benefit from inheretence,
then you also will want to be using code behind. Inheritence of code
contained in .aspx files is painful at absolute best.

And of course, you might want to use private key pairs and strong names to
validate your web application hasn't been tampered with. You do this by
putting the business logic in the GAC, and strongly naming your code. The
code in the GAC is much harder to attack, so if it knows the strong names of
authorized callers, then an attacker must have the keys to modify the
application code.

But because aspx files generate their code automatically, every time they
are run, you can't easily strongly name them. And so you must use code
behind if it is important to have mutual validation. The trick to
accomplishing this is inheritence.

 

[fd123456]

Kevin, that was ... hofstadterian, is there such a word?

This thread is getting rather long, and there is a very small detail
that Tom forgot to tell, that has been slightly overlooked, IMHO : Tom
DOESN'T use VS. He codes everything without Intellisense, without the
tabbed pages, the shortcuts, the code completion and all the candy
that we take for granted.

And everyone is trying to divide reasons for using code-behind -or
not- into "short or large programs", "short-lived or expandable
programs", "good or bad programmers"... Isn't the divide simply:
code-behind is a breeze when using VS, and hell when not?

Note that most of those who use Dreamweaver (or Notepad) say it's
hell, and others who talk about code-completion (and hence have VS)
say it's a breeze.

Well, my 2 cents...

Michel

 

[Alan Silver]

The arguement for Code Behind is simple.

Let's rephrase that slightly and say *an* argument, not *the* argument.
I agree that in the case when you want to do this, code-behind gives a
great advantage, but for those of us who have never had this need, nor
envisage it as a likely possibility, it's not a very compelling
argument.

A typical "real" ASP.NET application also will have classes that aren't part
of the user interface. In the real world, giving your web server that is
exposed to the public internet direct access to your SQL Server is a serious
security risk, one that can be exploited to gain access to information you
may not want attackers to have access to (such as credit card numbers, e-mail
addresses, etc.)

As mentioned several times in this thread, that's an issue of taking
certain parts of code into separate modules and is little to do with
code-behind vs code-beside. You can separate out modules either way.

Also, if your application is complicated enough to benefit from inheretence,
then you also will want to be using code behind. Inheritence of code
contained in .aspx files is painful at absolute best.

OK, a valid point, but again, not something that's relevant to most
people most of the time.

And of course, you might want to use private key pairs and strong names to
validate your web application hasn't been tampered with. You do this by
putting the business logic in the GAC, and strongly naming your code. The
code in the GAC is much harder to attack, so if it knows the strong names of
authorized callers, then an attacker must have the keys to modify the
application code.

Ditto

Don't get me wrong, I'm not arguing in principle, there are many times
when code-behind has strong advantages, but equally there are many times
when code-beside has the advantages. I just get fed up of the blanket
statements to the effect that code-behind is better and that's the end
of the discussion. I'm not saying you do this, I'm saying it happens a
lot and seems to be an inaccurate approach to the issue.

Ta ra