What's the difference/advantages between code behind and code inside?

[Alan Silver]

If I understood correctly, with code-behind, all the code goes into one

Your *compiled pages* go into the "Temporary ASP.NET files" directory
at "drive:\%windir%\Microsoft.Net\Framework\Version\ Temporary ASP.NET
files" directory.

Take a look at that directory, and see all the results of the
JIT-compilation which requesting your ASP.NET pages has created

I had a look in there and got confused!! There's all sorts of stuff,
mostly not readable by me ;-)

Anyway, thanks for the explanation, I think the fog is beginning to
clear.

 

[Kevin Spencer]

Well, Alan, if you follow best practices, and keep all the code at the top
of the page, there isn't much difference. Still, I like to use Visual
Studio, set up break points, etc., for debugging.

--
HTH,

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

 

[tshad]

ease of reading is enough for me....

That is what I hear all the time, but I don't agree with that.

On one page you have the code at the top all together (unlike asp). So you
have the defacto separation. In the code behind page, you have to get past
all the imports, object definitions as well as any code VS adds (if you are
using VS).

Now if you could tell me that by compiling the code separately it would load
and run faster, then you might have something. But everyone says there is
no difference.

So I don't see how it is easier to read.

IMHO

Tom

FYI, in the new VS you should be able to "push a button" and switch your
model from code-behind to in-line or back again.

 

[Kevin Spencer]

So I don't see how it is easier to read.

ASP.Net is not procedural in nature. It is object-oriented and event-driven.
A large ASP.Net enterprise application includes not just individual
disconnected pages, but libraries of business logic and other classes, and
the execution jumps all over the place. A single ASP.Net page often has
dependencies on several external classes. This means that you're not just
looking at the Page code when you're debugging. You're debugging all the
dependencies as well. So, having the business logic of the Page class in a
separate file certainly adds no complexity to the app, but rather
encapsulates the Page business code in a separate class that can be debugged
separately from the presentation template.

If you've never worked in a team, or worked on large-scale web apps, you may
not fully appreciate the saving in time that good code organization
provides.

--
HTH,

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

ease of reading is enough for me....

That is what I hear all the time, but I don't agree with that.

On one page you have the code at the top all together (unlike asp). So
you have the defacto separation. In the code behind page, you have to get
past all the imports, object definitions as well as any code VS adds (if
you are using VS).

Now if you could tell me that by compiling the code separately it would
load and run faster, then you might have something. But everyone says
there is no difference.

So I don't see how it is easier to read.

IMHO

Tom

 

[tshad]

ASP.Net is not procedural in nature. It is object-oriented and
event-driven. A large ASP.Net enterprise application includes not just
individual disconnected pages, but libraries of business logic and other
classes, and the execution jumps all over the place. A single ASP.Net page
often has dependencies on several external classes. This means that you're
not just looking at the Page code when you're debugging. You're debugging
all the dependencies as well. So, having the business logic of the Page
class in a separate file certainly adds no complexity to the app, but
rather encapsulates the Page business code in a separate class that can be
debugged separately from the presentation template.

If you've never worked in a team, or worked on large-scale web apps, you
may not fully appreciate the saving in time that good code organization
provides.

You missed my point.

I agree with your assessment.

That doesn't necessarily make it easier to read.

"A large ASP.Net enterprise application includes not just individual
disconnected pages, but libraries of business logic and other classes, and
the execution jumps all over the place."

same as

"A single ASP.Net page often has dependencies on several external classes.
This means that you're not just looking at the Page code when you're
debugging. "

In both cases you are looking at multiple pages. So "libraries of business
logic and other classes and the execution jumps all over the place" is
easier to read?

Doesn't fly.

It may be more structured, but not necessarily easier to read (which was my
point)

 

[Alan Silver]

Well, Alan, if you follow best practices, and keep all the code at the top

of the page, there isn't much difference.

All of the samples I have seen so far had all the code (except for the
odd <%=%>) at the top. I didn't think you could do it any other way in
ASP.NET ;-)

That could explain why I couldn't see a difference!!

However, if code at the top of the page is the right way to do it, then
I shall look scornfully upon the face of any pages that I see mixing the
code with the HTML. I shall pronounce them unclean, verily I will cast
them out from my abode ;-)

Still, I like to use Visual
Studio, set up break points, etc., for debugging.

Does VS force you into code-behind? If not, I'm not sure what you're
getting at here. Can't you set up break points and debug code-inside
pages with VS? If not, then it sounds like a serious deficiency.

Thanks for the reply

 

[Kevin Spencer]

Does VS force you into code-behind? If not, I'm not sure what you're

getting at here. Can't you set up break points and debug code-inside pages
with VS? If not, then it sounds like a serious deficiency.

Not with any released version of VS.Net. I believe (but am not sure) that
VS.Net 2005 may support this.

--
HTH,

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

 

[Alan Silver]

Does VS force you into code-behind? If not, I'm not sure what you're

Not with any released version of VS.Net. I believe (but am not sure)
that VS.Net 2005 may support this.

Sure sounds like a badly missing feature if it can't debug code-inside.
I haven't got VS yet, I'm waiting for 2005 to be released, so we'll see
what that offers.

Ta ra

 

[Guest]

Inline code writing is fine when it is fairly simple application. Code behind
feature helps you to isolate code from view. (intent behind MVC design
pattern). This also enables easier maintenance of the code. Also if we want
to write re-usable code this feature enables to achieve as we can keep common
code in base class and inherit the page class from the same.
I hope this helps.

 

[tshad]

Inline code writing is fine when it is fairly simple application. Code
behind
feature helps you to isolate code from view. (intent behind MVC design
pattern). This also enables easier maintenance of the code. Also if we
want
to write re-usable code this feature enables to achieve as we can keep
common
code in base class and inherit the page class from the same.
I hope this helps.

This was the point I was trying to make.

Code-inside is perfectly viable under some circumstances.

Code behind does add a little more complexity (not a lot, but a little) and
you get benefit from that. This would not necessarily be necessary for a
small application.

Tom

 

[Kevin Spencer]

Code behind does add a little more complexity (not a lot, but a little)

and you get benefit from that. This would not necessarily be necessary
for a small application.

True, but Best Practices take practice! Watch your pennies, and the dollars
will take care of themselves. IOW, unless you plan to work on small stuff
forever, you might want to get into practice for the big stuff now.
Otherwise, you'll have to learn it all over again after getting in the habit
of doing it the wrong way.

--
HTH,

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

 

[Guest]

I'm with Kevin Spencer, Code-behind follows the Model-View-Controller pattern
that separates the UI Controller code from the UI itself. Many developers
extend this principal to make separate assemblies for controller and data
models for unit testing and reuse. It's also called
Boundary-Entity-Controller if you're wondering.

 

[Guest]

fyi, so can code-behind with the right compile flags
Can you give a 10 second example, I know that an ASPX will be recompiled if
you put a new one on the server but are you saying the .cs or .vb files can
also be left for the server to recompile on a first visit to the new files -
what configuration settings do I need for this?

Cheers

 

[Guest]

Hi people,

Good question. I was curious what that meant too. ;o)

From what I could understand at first reading, I think the writer meant
"old-fashioned modular programming", as people are already used to do it. The
word "professional" is a little unfortunate here but from my point of view it
could mean "abstraction", as programmers know, the more abstraction you have,
more professional-like job it seems to be (just a feeling...).
We evolved from card-punching manual instruction code writing to more
modular, organized, abstracted, oriented programming that consequently
allowed to create larger programmer teams (and more professional if you may
say it). It is natural to say that the evolution from "writing code mixed
with html" to modular code-behind concept is analog to the idea I've just
described above.

Anyway, good day to you all.
Dario Andrade

 

[Guest]

In ASP.NET 2.0 you'll get dynamical compilation no matter if you’re

putting your code into the ASPX file or in a codebehind file. In
addition you'll be able to deploy your code in compiled form without
sourcecode, even if you decide to write your code in line the ASPX file.

Anders Norås, could you please explain this a bit, what i understand from
your statement is that it is possible to deploy ASP.NET application in
compiled form. Are you refeing to the dll(compiled form of cs or vb file) OR
is it possible to compile the aspx(html code) also?? If yes, could you please
explain how to do that?

Puneet Gupta

 

[Patrice]

See :
http://msdn.microsoft.com/asp.net/w...us/dnvs05/html/internals.asp#internals_topic3

It explains the new compilation options available in ASP.NET 2.0

Patrice

--

 

[Guest]

If all this talk of MVC etc is confusing, you might want to have a look at
this document

http://msdn.microsoft.com/architect...x?pull=/library/en-us/dnpatterns/html/Esp.asp

It explains some best practices regarding use of .net patterns. There is an
excellent section on MVC and other useful patterns. Will assist in not
re-inventing the wheel.

Thanks

Barry

 

[Alan Silver]

If all this talk of MVC etc is confusing, you might want to have a look at

this document

Erm, what's MVC? I don't remember that coming up (unless I missed the
abbreviation).

http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/libra
ry/en-us/dnpatterns/html/Esp.asp

It explains some best practices regarding use of .net patterns. There is an
excellent section on MVC and other useful patterns. Will assist in not
re-inventing the wheel.

Thanks, looks quite confusing itself!! 350 pages!! I think it's about
time MS invented Virtual Programmer, a clone that can do all the reading
and research while you do the actual work!!

Thanks for the link