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

[Alan Silver]

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Murray Jack]

According to reports ive read there is no difference between the 2 in terms
of performance

I personally refer to use code behind as its more like the VB editors im
used to but i guess its up to you

Hope this helps


"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have understood
correctly, means that the script code goes in a separate file from the
HTML. Apart from the obvious advantage if you have a separate designer and
programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Eliyahu Goldin]

In-page script can be changed on the site without re-deploying the whole
application.

Code behind lets you write program modules in a regular professional way.

Eliyahu

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Curt_C [MVP]]

ease of reading is enough for me....

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.

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have understood
correctly, means that the script code goes in a separate file from the
HTML. Apart from the obvious advantage if you have a separate designer and
programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Curt_C [MVP]]

"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:em**************@TK2MSFTNGP09.phx.gbl...

In-page script can be changed on the site without re-deploying the whole
application.

fyi, so can code-behind with the right compile flags

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com

[Eliyahu Goldin]

But you don't usually deploy code-behind.

Eliyahu

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:em**************@TK2MSFTNGP09.phx.gbl...

In-page script can be changed on the site without re-deploying the whole
application.

fyi, so can code-behind with the right compile flags

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com

[Alan Silver]

>In-page script can be changed on the site without re-deploying the whole

application.
Pardon my (admitted) ignorance, but why does code-behind require you to
redeploy the whole application? Maybe I'm just not sure what happens to
code-behind code when it gets compiled, I just assumed that either way
it went into a similar file.
Code behind lets you write program modules in a regular professional way.
What does that mean? Surely professional programming is down to the
programmer getting it right, not a choice of where to place the code.
Please explain what you mean by this.

Thanks for the reply.
Eliyahu
Nice name, I have a son with that name ;-)
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Kevin Spencer]

Separation of code and content.

--
HTH,

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

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have understood
correctly, means that the script code goes in a separate file from the
HTML. Apart from the obvious advantage if you have a separate designer and
programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Anders Norås]

Alan Silver wrote:

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

Codebehind is code that a web form, user control or web service uses
which is not located in the ASPX file. The design process of separating
code from the ASPX markup has many advantages. Most importantly; it
allows web designers to work with the HTML without messing up the
application code. Visual Studio .NET has almost no support for coding
within an ASPX page using <script runat="server> in line code, so the
codebehind model is the most widely used amongst ASP.NET developers.
Visual Studio .NET uses the codebehind attribute by default. This
attribute is completely ignored by the ASP.NET runtime. It is there to
enable Visual Studio .NET to associate ASPX files with their codebehind
files during development.

Visual Studio .NET compiles all codebehind classes to a single assembly
which is placed in the web application's "bin" folder when you build the
project. Therefore there is no need to deploy the *.aspx.cs or *.aspx.vb
files. Deploying the application code in a compiled assembly helps
protect intellectual property, because you don't have to make the source
code available.
You can configure ASP.NET to JIT compile the codebehind files, removing
the need for precompiled assemblies.

In line code can be a the right choice if your application is hosted by
a third party, where it is difficult to deploy compiled code to the
server or where you want to take advantage of JIT compilation of the
application code without having to tweak ASP.NET settings.

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.

Personally I prefer to use codebehind in "real" projects and in line
code for short examples.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

[Curt_C [MVP]]

but you could... if you wanted that model, thats all I was saying :}

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com
"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:ul**************@TK2MSFTNGP09.phx.gbl...

But you don't usually deploy code-behind.

Eliyahu

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:em**************@TK2MSFTNGP09.phx.gbl...

> In-page script can be changed on the site without re-deploying the
> whole
> application.
>

fyi, so can code-behind with the right compile flags

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com

[Alan Silver]

>Separation of code and content.

But you have that with code-inside. Not separated into two files, but
what's the advantage of that anyway (except for when you have a designer
and a programmer working on the same page at the same time)?

Thanks for the reply

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>Visual Studio .NET compiles all codebehind classes to a single assembly

which is placed in the web application's "bin" folder when you build
the project. Therefore there is no need to deploy the *.aspx.cs or
*.aspx.vb files. Deploying the application code in a compiled assembly
helps protect intellectual property, because you don't have to make the
source code available.
If I've got it right, then code-inside results in one file per ASP.NEt
page, and code behind results in one file per page, plus one extra file
containing the guts of the code. Correct?

If so, it's a bit like bunging all your code into a COM DLL (in Classic
ASP) and just making the calls from the ASP, except that you don't
actually need to make the calls? If so, then I can see the advantage.

I have an e-commerce package written in VB COM and ASP. There is one
DLL, and I can build as many sites as I like, each with its own
graphical feel, but all using the same underlying code. If I understand
you correctly, this could be done with code-behind. Write the code once,
then just write the HTML bits for each new site. With code-inside, I
would have to copy the code into each page for each site.

Or did I miss it completely?
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.
So what happens to the compiled code? Do you get one file per page, or
one file for the whole application? This interests me as I'm trying to
learn ASP.NET for 2.0 as there's little point in learning 1.1, only to
have to relearn parts of it for 2.0
Personally I prefer to use codebehind in "real" projects and in line
code for short examples.

Sounds reasonable. Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[darrel]

> Pardon my (admitted) ignorance, but why does code-behind require you to

redeploy the whole application?

Normally, when using codebehind, you end up compiling all your codebehind
pages into one DLL. So, for each change in codebehind scrips, you need to
recompile, then reupload the DLL.

When finished, you end up with a bunch of ASPX pages and one DLL on the
server.

Code behind lets you write program modules in a regular professional way.

What does that mean?

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

-Darrel

[Juan T. Llibre]

re:

So what happens to the compiled code?
Do you get one file per page, or one
file for the whole application?

It looks like you're confusing the compilation of an application's
assemblies by either VS.NET or via a command-line build,
with the JIT ( just-in-time ) compilation which occurs when
a page is requested by a client.

JIT compilation occurs whether the code is in code-behind,
or it's in an aspx page which calls functions/classes in a
pre-compiled assembly.


Juan T. Llibre
ASP.NET MVP
===========
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ks**************@nospamthankyou.spam...

Visual Studio .NET compiles all codebehind classes to a single assembly
which is placed in the web application's "bin" folder when you build the
project. Therefore there is no need to deploy the *.aspx.cs or *.aspx.vb
files. Deploying the application code in a compiled assembly helps
protect intellectual property, because you don't have to make the source
code available.

If I've got it right, then code-inside results in one file per ASP.NEt
page, and code behind results in one file per page, plus one extra file
containing the guts of the code. Correct?

If so, it's a bit like bunging all your code into a COM DLL (in Classic
ASP) and just making the calls from the ASP, except that you don't
actually need to make the calls? If so, then I can see the advantage.

I have an e-commerce package written in VB COM and ASP. There is one DLL,
and I can build as many sites as I like, each with its own graphical feel,
but all using the same underlying code. If I understand you correctly,
this could be done with code-behind. Write the code once, then just write
the HTML bits for each new site. With code-inside, I would have to copy
the code into each page for each site.

Or did I miss it completely?

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.

So what happens to the compiled code? Do you get one file per page, or one
file for the whole application? This interests me as I'm trying to learn
ASP.NET for 2.0 as there's little point in learning 1.1, only to have to
relearn parts of it for 2.0

Personally I prefer to use codebehind in "real" projects and in line code
for short examples.

Sounds reasonable. Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[darrel]

> If I've got it right, then code-inside results in one file per ASP.NEt

page, and code behind results in one file per page, plus one extra file
containing the guts of the code. Correct?

With code-inside, you only have one file per 'page'...the aspx page.

With code-behind, you have two files per 'page' the aspx page and the
aspx.vb/cs/etc page.

So, with both methods, you end up with the same number of aspx pages. The
difference is that with codebehind, all your aspx.vb/cs/etc pages can be
compiled into one DLL.

-Darrel

[Alan Silver]

>> Pardon my (admitted) ignorance, but why does code-behind require you to

redeploy the whole application?

Normally, when using codebehind, you end up compiling all your codebehind
pages into one DLL. So, for each change in codebehind scrips, you need to
recompile, then reupload the DLL.

When finished, you end up with a bunch of ASPX pages and one DLL on the
server.

Thanks, that confirms what I thought Anders was saying.

>Code behind lets you write program modules in a regular professional way.

What does that mean?

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

Oh good, I don't feel like the only non-guru round here!!

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>> So what happens to the compiled code?

Do you get one file per page, or one
file for the whole application?
It looks like you're confusing the compilation of an application's
assemblies by either VS.NET or via a command-line build,
with the JIT ( just-in-time ) compilation which occurs when
a page is requested by a client.

Probably!! I'm not really clear on what either means!!
JIT compilation occurs whether the code is in code-behind,
or it's in an aspx page which calls functions/classes in a
pre-compiled assembly.
Sorry, no clearer ;-(

If I understood correctly, with code-behind, all the code goes into one
DLL, leaving just the HTML bits in the ASPX files. With code-inside, the
code stays with its HTML, and when the page is compiled, you get a
compiled version of the code/HTML combination.

If that's right, then how does this change in ASP.NET 2.0? Or doesn't
it, maybe I misunderstood what was meant.

All too much for my little brain on this little sleep!!
Juan T. Llibre
ASP.NET MVP
===========
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ks**************@nospamthankyou.spam...

>Visual Studio .NET compiles all codebehind classes to a single assembly
>which is placed in the web application's "bin" folder when you build the
>project. Therefore there is no need to deploy the *.aspx.cs or *.aspx.vb
>files. Deploying the application code in a compiled assembly helps
>protect intellectual property, because you don't have to make the source
>code available.

If I've got it right, then code-inside results in one file per ASP.NEt
page, and code behind results in one file per page, plus one extra file
containing the guts of the code. Correct?

If so, it's a bit like bunging all your code into a COM DLL (in Classic
ASP) and just making the calls from the ASP, except that you don't
actually need to make the calls? If so, then I can see the advantage.

I have an e-commerce package written in VB COM and ASP. There is one DLL,
and I can build as many sites as I like, each with its own graphical feel,
but all using the same underlying code. If I understand you correctly,
this could be done with code-behind. Write the code once, then just write
the HTML bits for each new site. With code-inside, I would have to copy
the code into each page for each site.

Or did I miss it completely?

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.

So what happens to the compiled code? Do you get one file per page, or one
file for the whole application? This interests me as I'm trying to learn
ASP.NET for 2.0 as there's little point in learning 1.1, only to have to
relearn parts of it for 2.0

Personally I prefer to use codebehind in "real" projects and in line code
for short examples.

Sounds reasonable. Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Kevin Spencer]

> But you have that with code-inside. Not separated into two files, but

what's the advantage of that anyway (except for when you have a designer
and a programmer working on the same page at the same time)?

In what way are they "separated?"

Separation of code and content, in fact, the entire principle of separation
of code into "functions," "tiers," "classes," "modules," and what-have-you
is extremely useful in terms of code debugging and maintenance. In fact, as
an ASP programmer, I got sick and tired of trying to slog through the mess
of tangled server-side code and HTML content that I often ran into. The
ASP.Net Page object model is intended to "encourage" programmers to
structure their code more logically. Of course, Microsoft is not so
Machiavellian that they truly "force" any programmer to do anything.
Instead, they give you defaults, and allow you to change them to your
heart's content. Of course, they also publish "Best Practices" articles to
help programmers learn how to best structure their applications and code
(read "codes" if you are a "Computer Professional").

--
HTH,

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

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ft**************@nospamthankyou.spam...

Separation of code and content.

But you have that with code-inside. Not separated into two files, but
what's the advantage of that anyway (except for when you have a designer
and a programmer working on the same page at the same time)?

Thanks for the reply

--
Alan Silver
(anything added below this line is nothing to do with me)

[Juan T. Llibre]

re:

If I understood correctly, with code-behind, all the code goes into one
DLL, leaving just the HTML bits in the ASPX files.

Well, you *could* call/manipulate the functions in your
compiled assemblies, in your .aspx files, and that would
be JIT-compiled into a page which modifies the results
of the compiled code in your assemblies, for example.

The key difference is that JIT-compilation
is different from assembly compilation.

JIT-compilation occurs when any ASP.NET *page* is requested.

Assembly compilation is done from the VS.NET IDE,
or from the command-line using csc.exe or vbc.exe,
before any client can even request a page.

Your compiled assemblies go either in the /bin directory,
or in the GAC ( Global Assembly Cache ).

Your *compiled pages* go into the "Temporary ASP.NET files"
directory at "drive:\%windir%\Microsoft.Net\Framework\Versi on\
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


Juan T. Llibre
ASP.NET MVP
===========
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:tc**************@nospamthankyou.spam...

So what happens to the compiled code?
Do you get one file per page, or one
file for the whole application?

It looks like you're confusing the compilation of an application's
assemblies by either VS.NET or via a command-line build,
with the JIT ( just-in-time ) compilation which occurs when
a page is requested by a client.

Probably!! I'm not really clear on what either means!!

JIT compilation occurs whether the code is in code-behind,
or it's in an aspx page which calls functions/classes in a
pre-compiled assembly.

Sorry, no clearer ;-(

If I understood correctly, with code-behind, all the code goes into one
DLL, leaving just the HTML bits in the ASPX files. With code-inside, the
code stays with its HTML, and when the page is compiled, you get a
compiled version of the code/HTML combination.

If that's right, then how does this change in ASP.NET 2.0? Or doesn't it,
maybe I misunderstood what was meant.

All too much for my little brain on this little sleep!!

Juan T. Llibre
ASP.NET MVP
===========
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ks**************@nospamthankyou.spam...

>Visual Studio .NET compiles all codebehind classes to a single assembly
>which is placed in the web application's "bin" folder when you build
>the
>project. Therefore there is no need to deploy the *.aspx.cs or
>*.aspx.vb
>files. Deploying the application code in a compiled assembly helps
>protect intellectual property, because you don't have to make the
>source
>code available.

If I've got it right, then code-inside results in one file per ASP.NEt
page, and code behind results in one file per page, plus one extra file
containing the guts of the code. Correct?

If so, it's a bit like bunging all your code into a COM DLL (in Classic
ASP) and just making the calls from the ASP, except that you don't
actually need to make the calls? If so, then I can see the advantage.

I have an e-commerce package written in VB COM and ASP. There is one
DLL,
and I can build as many sites as I like, each with its own graphical
feel,
but all using the same underlying code. If I understand you correctly,
this could be done with code-behind. Write the code once, then just
write
the HTML bits for each new site. With code-inside, I would have to copy
the code into each page for each site.

Or did I miss it completely?

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.

So what happens to the compiled code? Do you get one file per page, or
one
file for the whole application? This interests me as I'm trying to learn
ASP.NET for 2.0 as there's little point in learning 1.1, only to have to
relearn parts of it for 2.0

Personally I prefer to use codebehind in "real" projects and in line
code
for short examples.

Sounds reasonable. Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>> But you have that with code-inside. Not separated into two files, but

what's the advantage of that anyway (except for when you have a designer
and a programmer working on the same page at the same time)?
In what way are they "separated?"

You can print out the entire page, take a pair of scissors and separate
the code from the HTML ;-)

Seriously, they occupy totally different parts of the file. I don't know
if it has to be that way, but all of the ones I've seen so far have all
the code at the top, then all of the HTML below. They could just as
easily be in two separate files, they just happen to be in the one. The
point is that they are not intertwined at all, unlike the ASP spaghetti.
Separation of code and content, in fact, the entire principle of separation
of code into "functions," "tiers," "classes," "modules," and what-have-you
is extremely useful in terms of code debugging and maintenance.
Agreed, but I'm not sure that separate files is an advantage over
separate parts of a single file. Maybe time will change my mind
(remember I'm really new at this), but at the moment I see the
advantages of separating the two, but not of physically splitting them
(except in the case where you have a designer and a programmer working
at the same time).
In fact, as
an ASP programmer, I got sick and tired of trying to slog through the mess
of tangled server-side code and HTML content that I often ran into.

Agreed, the ASP.NET way is much neater. I've worked that bit out!!

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

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

DLL, leaving just the HTML bits in the ASPX files.

<snip>Your *compiled pages* go into the "Temporary ASP.NET files" directory
at "drive:\%windir%\Microsoft.Net\Framework\Versi on\ 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.

--
Alan Silver
(anything added below this line is nothing to do with me)

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

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:mM**************@nospamthankyou.spam...

But you have that with code-inside. Not separated into two files, but
what's the advantage of that anyway (except for when you have a designer
and a programmer working on the same page at the same time)?

In what way are they "separated?"

You can print out the entire page, take a pair of scissors and separate
the code from the HTML ;-)

Seriously, they occupy totally different parts of the file. I don't know
if it has to be that way, but all of the ones I've seen so far have all
the code at the top, then all of the HTML below. They could just as easily
be in two separate files, they just happen to be in the one. The point is
that they are not intertwined at all, unlike the ASP spaghetti.

Separation of code and content, in fact, the entire principle of
separation
of code into "functions," "tiers," "classes," "modules," and what-have-you
is extremely useful in terms of code debugging and maintenance.

Agreed, but I'm not sure that separate files is an advantage over separate
parts of a single file. Maybe time will change my mind (remember I'm
really new at this), but at the moment I see the advantages of separating
the two, but not of physically splitting them (except in the case where
you have a designer and a programmer working at the same time).

In fact, as
an ASP programmer, I got sick and tired of trying to slog through the mess
of tangled server-side code and HTML content that I often ran into.

Agreed, the ASP.NET way is much neater. I've worked that bit out!!

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

[tshad]

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:ut**************@tk2msftngp13.phx.gbl...

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.

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have understood
correctly, means that the script code goes in a separate file from the
HTML. Apart from the obvious advantage if you have a separate designer
and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eN**************@TK2MSFTNGP11.phx.gbl...

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:ut**************@tk2msftngp13.phx.gbl...

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.

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[tshad]

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

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.

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) :) --
HTH,

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eN**************@TK2MSFTNGP11.phx.gbl...

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:ut**************@tk2msftngp13.phx.gbl...

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.

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:ls**************@nospamthankyou.spam...
Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate
file from the HTML. Apart from the obvious advantage if you have a
separate designer and programmer, are there any other advantages to
code behind?

Most of the stuff I've seen so far uses code inside, but that's
probably because I'm still reading introductions and tutorials. It
looks sensible to me, as all the code is in one file (I can't afford to
employ a designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[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

--
Alan Silver
(anything added below this line is nothing to do with me)

[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" <al*********@nospam.thanx> wrote in message
news:Ca**************@nospamthankyou.spam...

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

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

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

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

--
Alan Silver
(anything added below this line is nothing to do with me)

[Gokul]

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.

"darrel" wrote:

If I've got it right, then code-inside results in one file per ASP.NEt
page, and code behind results in one file per page, plus one extra file
containing the guts of the code. Correct?

With code-inside, you only have one file per 'page'...the aspx page.

With code-behind, you have two files per 'page' the aspx page and the
aspx.vb/cs/etc page.

So, with both methods, you end up with the same number of aspx pages. The
difference is that with codebehind, all your aspx.vb/cs/etc pages can be
compiled into one DLL.

-Darrel

[tshad]

"Gokul" <Go***@discussions.microsoft.com> wrote in message
news:08**********************************@microsof t.com...

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
"darrel" wrote:

> If I've got it right, then code-inside results in one file per ASP.NEt
> page, and code behind results in one file per page, plus one extra file
> containing the guts of the code. Correct?

With code-inside, you only have one file per 'page'...the aspx page.

With code-behind, you have two files per 'page' the aspx page and the
aspx.vb/cs/etc page.

So, with both methods, you end up with the same number of aspx pages. The
difference is that with codebehind, all your aspx.vb/cs/etc pages can be
compiled into one DLL.

-Darrel

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:uy**************@tk2msftngp13.phx.gbl... "Gokul" <Go***@discussions.microsoft.com> wrote in message
news:08**********************************@microsof t.com...

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

"darrel" wrote:

> If I've got it right, then code-inside results in one file per ASP.NEt
> page, and code behind results in one file per page, plus one extra
> file
> containing the guts of the code. Correct?

With code-inside, you only have one file per 'page'...the aspx page.

With code-behind, you have two files per 'page' the aspx page and the
aspx.vb/cs/etc page.

So, with both methods, you end up with the same number of aspx pages.
The
difference is that with codebehind, all your aspx.vb/cs/etc pages can be
compiled into one DLL.

-Darrel

[Suman Chakrabarti [MCP]]

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.

"Alan Silver" wrote:

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[PaulP]

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

"Curt_C [MVP]" wrote:

but you could... if you wanted that model, thats all I was saying :}

--
Curt Christianson
Site & Scripts: http://www.Darkfalz.com
Blog: http://blog.Darkfalz.com

[Dario Andrade]

Hi people,

"darrel" wrote:

Code behind lets you write program modules in a regular professional way.

What does that mean?

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

[Puneet Gupta]

> 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





"Anders Norås" wrote:
Alan Silver wrote:

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

Codebehind is code that a web form, user control or web service uses
which is not located in the ASPX file. The design process of separating
code from the ASPX markup has many advantages. Most importantly; it
allows web designers to work with the HTML without messing up the
application code. Visual Studio .NET has almost no support for coding
within an ASPX page using <script runat="server> in line code, so the
codebehind model is the most widely used amongst ASP.NET developers.
Visual Studio .NET uses the codebehind attribute by default. This
attribute is completely ignored by the ASP.NET runtime. It is there to
enable Visual Studio .NET to associate ASPX files with their codebehind
files during development.

Visual Studio .NET compiles all codebehind classes to a single assembly
which is placed in the web application's "bin" folder when you build the
project. Therefore there is no need to deploy the *.aspx.cs or *.aspx.vb
files. Deploying the application code in a compiled assembly helps
protect intellectual property, because you don't have to make the source
code available.
You can configure ASP.NET to JIT compile the codebehind files, removing
the need for precompiled assemblies.

In line code can be a the right choice if your application is hosted by
a third party, where it is difficult to deploy compiled code to the
server or where you want to take advantage of JIT compilation of the
application code without having to tweak ASP.NET settings.

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.

Personally I prefer to use codebehind in "real" projects and in line
code for short examples.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

[Patrice]

See :
http://msdn.microsoft.com/asp.net/wh...ternals_topic3

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

Patrice

--

"Puneet Gupta" <Puneet Gu***@discussions.microsoft.com> a écrit dans le
message de news:4D**********************************@microsof t.com...

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





"Anders Norås" wrote:

Alan Silver wrote:

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

Codebehind is code that a web form, user control or web service uses
which is not located in the ASPX file. The design process of separating
code from the ASPX markup has many advantages. Most importantly; it
allows web designers to work with the HTML without messing up the
application code. Visual Studio .NET has almost no support for coding
within an ASPX page using <script runat="server> in line code, so the
codebehind model is the most widely used amongst ASP.NET developers.
Visual Studio .NET uses the codebehind attribute by default. This
attribute is completely ignored by the ASP.NET runtime. It is there to
enable Visual Studio .NET to associate ASPX files with their codebehind
files during development.

Visual Studio .NET compiles all codebehind classes to a single assembly
which is placed in the web application's "bin" folder when you build the
project. Therefore there is no need to deploy the *.aspx.cs or *.aspx.vb
files. Deploying the application code in a compiled assembly helps
protect intellectual property, because you don't have to make the source
code available.
You can configure ASP.NET to JIT compile the codebehind files, removing
the need for precompiled assemblies.

In line code can be a the right choice if your application is hosted by
a third party, where it is difficult to deploy compiled code to the
server or where you want to take advantage of JIT compilation of the
application code without having to tweak ASP.NET settings.

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.

Personally I prefer to use codebehind in "real" projects and in line
code for short examples.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

[Barry]

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

http://msdn.microsoft.com/architectu...s/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" wrote:

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

[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/architectu...px?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
Thanks

Barry
"Alan Silver" wrote:

Hello,

Newbie here, so please forgive what is probably a basic question ...

I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes in a separate file
from the HTML. Apart from the obvious advantage if you have a separate
designer and programmer, are there any other advantages to code behind?

Most of the stuff I've seen so far uses code inside, but that's probably
because I'm still reading introductions and tutorials. It looks sensible
to me, as all the code is in one file (I can't afford to employ a
designer!!), albeit conveniently separated into sections.

So, any advantage of code behind? Thanks in advance for all and any
(helpful) responses.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)