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

Discussion in 'ASP .Net' started by Alan Silver, Jan 27, 2005.

  1. Alan Silver

    Alan Silver Guest

    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, Jan 27, 2005
    #1
    1. Advertising

  2. Alan Silver

    Murray Jack Guest

    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" <> wrote in message
    news:...
    > 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, Jan 27, 2005
    #2
    1. Advertising

  3. 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" <> wrote in message
    news:...
    > 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, Jan 27, 2005
    #3
  4. Alan Silver

    Curt_C [MVP] Guest

    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" <> wrote in message
    news:...
    > 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], Jan 27, 2005
    #4
  5. Alan Silver

    Curt_C [MVP] Guest

    "Eliyahu Goldin" <> wrote in message
    news:...
    > 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
    Curt_C [MVP], Jan 27, 2005
    #5
  6. But you don't usually deploy code-behind.

    Eliyahu

    "Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
    news:%...
    > "Eliyahu Goldin" <> wrote in message
    > news:...
    > > 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, Jan 27, 2005
    #6
  7. Alan Silver

    Alan Silver Guest

    >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" <> wrote in message
    >news:...
    >> 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)
    Alan Silver, Jan 27, 2005
    #7
  8. Separation of code and content.

    --
    HTH,

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

    "Alan Silver" <> wrote in message
    news:...
    > 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, Jan 27, 2005
    #8
  9. Re: What's the difference/advantages between code behind and codeinside?

    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/
    =?windows-1252?Q?Anders_Nor=E5s?=, Jan 27, 2005
    #9
  10. Alan Silver

    Curt_C [MVP] Guest

    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" <> wrote in message
    news:...
    > But you don't usually deploy code-behind.
    >
    > Eliyahu
    >
    > "Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
    > news:%...
    >> "Eliyahu Goldin" <> wrote in message
    >> news:...
    >> > 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
    >>
    >>

    >
    >
    Curt_C [MVP], Jan 27, 2005
    #10
  11. Alan Silver

    Alan Silver Guest

    >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, Jan 27, 2005
    #11
  12. Alan Silver

    Alan Silver Guest

    >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, Jan 27, 2005
    #12
  13. Alan Silver

    darrel Guest

    > 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
    darrel, Jan 27, 2005
    #13
  14. 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" <> wrote in message
    news:...
    > >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)
    Juan T. Llibre, Jan 27, 2005
    #14
  15. Alan Silver

    darrel Guest

    > 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
    darrel, Jan 27, 2005
    #15
  16. Alan Silver

    Alan Silver Guest

    >> 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, Jan 27, 2005
    #16
  17. Alan Silver

    Alan Silver Guest

    >> 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" <> wrote in message
    >news:...
    >> >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, Jan 27, 2005
    #17
  18. > 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" <> wrote in message
    news:...
    > >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)
    Kevin Spencer, Jan 27, 2005
    #18
  19. 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" <> wrote in message
    news:tcgwS$...
    >>> 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" <> wrote in message
    >>news:...
    >>> >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)
    Juan T. Llibre, Jan 27, 2005
    #19
  20. Alan Silver

    Alan Silver Guest

    >> 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, Jan 27, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ben Miller [msft]

    Re: Code Behind vs. no code behind: error

    Ben Miller [msft], Jun 27, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    570
    Alphonse Giambrone
    Jun 28, 2003
  2. jakk
    Replies:
    4
    Views:
    12,059
  3. keithb
    Replies:
    1
    Views:
    889
    Bruce Barker
    Mar 29, 2006
  4. John

    Non-code behind to code behind

    John, Feb 19, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    466
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Feb 19, 2007
  5. sumankumar
    Replies:
    0
    Views:
    441
    sumankumar
    Aug 25, 2007
Loading...

Share This Page