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

A

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

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
 
E

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
 
C

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

Curt_C [MVP]

Eliyahu Goldin said:
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
 
A

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.

Nice name, I have a son with that name ;-)
 
K

Kevin Spencer

Separation of code and content.

--
HTH,

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

=?windows-1252?Q?Anders_Nor=E5s?=

Alan said:
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/
 
A

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
 
A

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

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.
What does that mean?

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

-Darrel
 
J

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

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
 
A

Alan Silver

Pardon my (admitted) ignorance, but why does code-behind require you to
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.
Good question. I was curious what that meant too. ;o)

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

Alan Silver

So what happens to the compiled code?
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
===========
 
K

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

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




Juan T. Llibre
ASP.NET MVP
===========
Alan Silver said:
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!!
 
A

Alan Silver

But you have that with code-inside. Not separated into two files, but
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top