TRICK: methods in ASPX pages with <%%> code blocks

Discussion in 'ASP .Net' started by John Rivers, Aug 23, 2005.

  1. John Rivers

    John Rivers Guest

    Hello,

    What good reason there is for not allowing methods in ASPX pages I
    can't imagine, but here is how to get around that limitation:

    (START)
    <body MS_POSITIONING="FlowLayout">

    <form id="Form1" method="post" runat="server">
    <%
    MyMethod(__output);
    %>
    </form>
    </body>
    </html>
    <%
    }
    void MyMethod(System.Web.UI.HtmlTextWriter __output) {
    %><input type="text" name="Name" value="some html"/><%
    %>
    (END)

    how this works:

    ASP.NET takes your ASPX code and inserts it into a hidden Render
    method that takes HtmlTextWriter as an argument

    we use "}" to close the current render method
    then declare a method that takes the same argument
    we don't need to put a closing brace because ASP.NET will
    do that for us
     
    John Rivers, Aug 23, 2005
    #1
    1. Advertising

  2. John Rivers

    Lucas Tam Guest

    "John Rivers" <> wrote in
    news::

    > What good reason there is for not allowing methods in ASPX pages I
    > can't imagine, but here is how to get around that limitation:


    It makes for messy code?

    --
    Lucas Tam ()
    Please delete "REMOVE" from the e-mail address when replying.
    http://members.ebay.com/aboutme/coolspot18/
     
    Lucas Tam, Aug 23, 2005
    #2
    1. Advertising

  3. John Rivers

    John Rivers Guest

    My Classic ASP isn't messy
    it is a beautiful set of classes that render html
    handles multi-branding
    perform top-notch best-of-practice datasheets and forms
    with full locking and security that run at full speed
    and can be tested quickly and easily

    what IS messy is a bunch of "UserControl" files
    which miss out on all the benefits of object oriented programming
    leave my ASPX pages full of messy register tags
    and non-standardised property accesses

    a UserControl is just a single method in a file
    instead of in a class where it belongs

    it is silly!
     
    John Rivers, Aug 23, 2005
    #3
  4. John Rivers

    Marina Guest

    Who says you can't have methods in the page?

    Just put your methods in <script runat="server"></server"

    And as someone mentioned, even though you can do this, you shouldn't. There
    is no reason you can't put it in a code behind file, or in a class library
    DLL.

    "John Rivers" <> wrote in message
    news:...
    > Hello,
    >
    > What good reason there is for not allowing methods in ASPX pages I
    > can't imagine, but here is how to get around that limitation:
    >
    > (START)
    > <body MS_POSITIONING="FlowLayout">
    >
    > <form id="Form1" method="post" runat="server">
    > <%
    > MyMethod(__output);
    > %>
    > </form>
    > </body>
    > </html>
    > <%
    > }
    > void MyMethod(System.Web.UI.HtmlTextWriter __output) {
    > %><input type="text" name="Name" value="some html"/><%
    > %>
    > (END)
    >
    > how this works:
    >
    > ASP.NET takes your ASPX code and inserts it into a hidden Render
    > method that takes HtmlTextWriter as an argument
    >
    > we use "}" to close the current render method
    > then declare a method that takes the same argument
    > we don't need to put a closing brace because ASP.NET will
    > do that for us
    >
     
    Marina, Aug 23, 2005
    #4
  5. John Rivers

    Karl Seguin Guest

    Then create custom server controls

    Karl

    --
    MY ASP.Net tutorials
    http://www.openmymind.net/ - New and Improved (yes, the popup is
    annoying)
    http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
    come!)
    "John Rivers" <> wrote in message
    news:...
    > My Classic ASP isn't messy
    > it is a beautiful set of classes that render html
    > handles multi-branding
    > perform top-notch best-of-practice datasheets and forms
    > with full locking and security that run at full speed
    > and can be tested quickly and easily
    >
    > what IS messy is a bunch of "UserControl" files
    > which miss out on all the benefits of object oriented programming
    > leave my ASPX pages full of messy register tags
    > and non-standardised property accesses
    >
    > a UserControl is just a single method in a file
    > instead of in a class where it belongs
    >
    > it is silly!
    >
     
    Karl Seguin, Aug 23, 2005
    #5
  6. John Rivers

    tom pester Guest

    I like my code and functions inside the aspx page itself unless the project
    architecture tells you otherwise.
    If you develop in a small team the separion isn't necessary and VWD now has
    full intellisense support for this scenario.

    The fact that you can't have pure html in a function annoyed me very much
    too when coming from cASP but you get used to it.
    I think they made it impossible for performance reasons cause mixing code
    with HTML did have a noticable negative perfermance effect.
    Maybe they wanted to eliminate a bad programming practice?

    Cheers,
    Tom Pester

    > Who says you can't have methods in the page?
    >
    > Just put your methods in <script runat="server"></server"
    >
    > And as someone mentioned, even though you can do this, you shouldn't.
    > There is no reason you can't put it in a code behind file, or in a
    > class library DLL.
    >
    > "John Rivers" <> wrote in message
    > news:...
    >
    >> Hello,
    >>
    >> What good reason there is for not allowing methods in ASPX pages I
    >> can't imagine, but here is how to get around that limitation:
    >>
    >> (START)
    >> <body MS_POSITIONING="FlowLayout">
    >> <form id="Form1" method="post" runat="server">
    >> <%
    >> MyMethod(__output);
    >> %>
    >> </form>
    >> </body>
    >> </html>
    >> <%
    >> }
    >> void MyMethod(System.Web.UI.HtmlTextWriter __output) {
    >> %><input type="text" name="Name" value="some html"/><%
    >> %>
    >> (END)
    >> how this works:
    >>
    >> ASP.NET takes your ASPX code and inserts it into a hidden Render
    >> method that takes HtmlTextWriter as an argument
    >>
    >> we use "}" to close the current render method
    >> then declare a method that takes the same argument
    >> we don't need to put a closing brace because ASP.NET will
    >> do that for us
     
    tom pester, Aug 23, 2005
    #6
  7. John Rivers

    Marina Guest

    Even when you develop in a small team, there are many advantages to not
    putting your code right in the .aspx.
    1) reusability - not unlikely your function will be useful elsewhere
    2) compile time error checking
    3) easier to read, as it's not mixed in with HTML

    list goes on and on.

    So yes, you can do it. But I still don't see why you would want to.

    "tom pester" <> wrote in message
    news:...
    >
    > I like my code and functions inside the aspx page itself unless the
    > project architecture tells you otherwise.
    > If you develop in a small team the separion isn't necessary and VWD now
    > has full intellisense support for this scenario.
    >
    > The fact that you can't have pure html in a function annoyed me very much
    > too when coming from cASP but you get used to it.
    > I think they made it impossible for performance reasons cause mixing code
    > with HTML did have a noticable negative perfermance effect.
    > Maybe they wanted to eliminate a bad programming practice?
    >
    > Cheers,
    > Tom Pester
    >
    >> Who says you can't have methods in the page?
    >>
    >> Just put your methods in <script runat="server"></server"
    >>
    >> And as someone mentioned, even though you can do this, you shouldn't.
    >> There is no reason you can't put it in a code behind file, or in a
    >> class library DLL.
    >>
    >> "John Rivers" <> wrote in message
    >> news:...
    >>
    >>> Hello,
    >>>
    >>> What good reason there is for not allowing methods in ASPX pages I
    >>> can't imagine, but here is how to get around that limitation:
    >>>
    >>> (START)
    >>> <body MS_POSITIONING="FlowLayout">
    >>> <form id="Form1" method="post" runat="server">
    >>> <%
    >>> MyMethod(__output);
    >>> %>
    >>> </form>
    >>> </body>
    >>> </html>
    >>> <%
    >>> }
    >>> void MyMethod(System.Web.UI.HtmlTextWriter __output) {
    >>> %><input type="text" name="Name" value="some html"/><%
    >>> %>
    >>> (END)
    >>> how this works:
    >>>
    >>> ASP.NET takes your ASPX code and inserts it into a hidden Render
    >>> method that takes HtmlTextWriter as an argument
    >>>
    >>> we use "}" to close the current render method
    >>> then declare a method that takes the same argument
    >>> we don't need to put a closing brace because ASP.NET will
    >>> do that for us

    >
    >
     
    Marina, Aug 23, 2005
    #7
  8. John Rivers

    tom pester Guest

    Hi Marina,

    > 1) reusability - not unlikely your function will be useful elsewhere


    If its a common function it should be in a class file and not in the code
    behind file right?
    The cases where you can reuse a code behind file are rare and I haven't spotted
    them in the wild.

    > 2) compile time error checking


    Doesn't asp.net version 2 solve this?

    > 3) easier to read, as it's not mixed in with HTML


    I am not saying to mix html with code. Thats a bad idea generaly.
    If I do everything in 1 file I still seperate logic from presentation but
    now I put all me code in the <script runat=server> block.
    The only difference is that the code is now embeded in the page itslef. That
    is the only difference.
    It's crucial that you understand this.

    > list goes on and on.


    What else?

    > So yes, you can do it. But I still don't see why you would want to.


    The code behind model has been pushed very hard in VS 2002/3 and the main
    reason I used it was the lack if intellisense in the aspx file.
    Now that this restriction is taken away why would I use a code behind?

    The question to ask is why would you put your code in a seperate file?

    I can think of 2 reasons :

    1) it _promotes_ (and nothing more) thinking where code is separated from
    presentation (MVC model)
    2) a designer can work on the aspx file while the programmer works on the
    code behind (that's not an argument of mine. I read it in the ms docs)

    I find these 2 arguments not good enough. Allthough the first point can be
    helpful for beginners.

    There is no reason for me to have 100 files in my project when I could have
    50 instead (or 1000/500 for that matter). I like to work fast and scrolling
    to the top of the page to alter some code is just that little faster.
    I don't like switching files. I know it takes maybe 1 second but when I program
    I switch betweeb files a lot. That argument doesn't hold on big monitors
    or dual views.

    I can't come up with any other reason that those 2 I mentioned.

    Cheers,
    Tom Pester


    > "tom pester" <> wrote in message
    > news:...
    >
    >> I like my code and functions inside the aspx page itself unless the
    >> project architecture tells you otherwise.
    >> If you develop in a small team the separion isn't necessary and VWD
    >> now
    >> has full intellisense support for this scenario.
    >> The fact that you can't have pure html in a function annoyed me very
    >> much
    >> too when coming from cASP but you get used to it.
    >> I think they made it impossible for performance reasons cause mixing
    >> code
    >> with HTML did have a noticable negative perfermance effect.
    >> Maybe they wanted to eliminate a bad programming practice?
    >> Cheers,
    >> Tom Pester
    >>> Who says you can't have methods in the page?
    >>>
    >>> Just put your methods in <script runat="server"></server"
    >>>
    >>> And as someone mentioned, even though you can do this, you
    >>> shouldn't. There is no reason you can't put it in a code behind
    >>> file, or in a class library DLL.
    >>>
    >>> "John Rivers" <> wrote in message
    >>> news:...
    >>>
    >>>> Hello,
    >>>>
    >>>> What good reason there is for not allowing methods in ASPX pages I
    >>>> can't imagine, but here is how to get around that limitation:
    >>>>
    >>>> (START)
    >>>> <body MS_POSITIONING="FlowLayout">
    >>>> <form id="Form1" method="post" runat="server">
    >>>> <%
    >>>> MyMethod(__output);
    >>>> %>
    >>>> </form>
    >>>> </body>
    >>>> </html>
    >>>> <%
    >>>> }
    >>>> void MyMethod(System.Web.UI.HtmlTextWriter __output) {
    >>>> %><input type="text" name="Name" value="some html"/><%
    >>>> %>
    >>>> (END)
    >>>> how this works:
    >>>> ASP.NET takes your ASPX code and inserts it into a hidden Render
    >>>> method that takes HtmlTextWriter as an argument
    >>>>
    >>>> we use "}" to close the current render method
    >>>> then declare a method that takes the same argument
    >>>> we don't need to put a closing brace because ASP.NET will
    >>>> do that for us
     
    tom pester, Aug 23, 2005
    #8
  9. John Rivers

    Marina Guest

    A code behind file is really a specialized class file. My point was, the
    code should be in something that gets compiled into a DLL. Whether it's in
    a class library that is unrelated to asp.net, or in a codebehind file - it
    is really the exact same thing. It gets compiled into a DLL.

    I don't know what 2.0 does, or how much it improved the IDE in that regard.

    In my opinion, having code in <script> tags, is mixing it with HTML. As in,
    there is HTML in that file, and there is code in that file. And it's all in
    there together.

    I find the 2 arguments you listed more then enough to support the reasons
    for doing it. Except with the change, that it more the promotes thinking
    about these 2 things as separate. There is a lot to be said from separating
    your UI from the business logic.

    And sorry, but your reasons for not doing just don't make sense to me. I
    don't care if I have 100 files or 50 files. You still just see one icon in
    VS, and you can either go to design view, or you can go to code. You don't
    see twice as many files - so who cares if in reality there are?

    It sounds like your UI and your business logic is all intermixed together.
    This will make it very difficult to re-architect (not that it sounds like
    there is a lot of architecture) or change things later on, since everything
    is all over the place.

    In any case, microsoft didn't limit anyone to any one model of how things
    should be done. If this way works for you, go ahead.

    "tom pester" <> wrote in message
    news:...
    > Hi Marina,
    >
    >> 1) reusability - not unlikely your function will be useful elsewhere

    >
    > If its a common function it should be in a class file and not in the code
    > behind file right?
    > The cases where you can reuse a code behind file are rare and I haven't
    > spotted them in the wild.
    >
    >> 2) compile time error checking

    >
    > Doesn't asp.net version 2 solve this?
    >
    >> 3) easier to read, as it's not mixed in with HTML

    >
    > I am not saying to mix html with code. Thats a bad idea generaly. If I do
    > everything in 1 file I still seperate logic from presentation but now I
    > put all me code in the <script runat=server> block.
    > The only difference is that the code is now embeded in the page itslef.
    > That is the only difference.
    > It's crucial that you understand this.
    >
    >> list goes on and on.

    >
    > What else?
    >
    >> So yes, you can do it. But I still don't see why you would want to.

    >
    > The code behind model has been pushed very hard in VS 2002/3 and the main
    > reason I used it was the lack if intellisense in the aspx file.
    > Now that this restriction is taken away why would I use a code behind?
    >
    > The question to ask is why would you put your code in a seperate file?
    > I can think of 2 reasons :
    >
    > 1) it _promotes_ (and nothing more) thinking where code is separated from
    > presentation (MVC model)
    > 2) a designer can work on the aspx file while the programmer works on the
    > code behind (that's not an argument of mine. I read it in the ms docs)
    >
    > I find these 2 arguments not good enough. Allthough the first point can be
    > helpful for beginners.
    >
    > There is no reason for me to have 100 files in my project when I could
    > have 50 instead (or 1000/500 for that matter). I like to work fast and
    > scrolling to the top of the page to alter some code is just that little
    > faster.
    > I don't like switching files. I know it takes maybe 1 second but when I
    > program I switch betweeb files a lot. That argument doesn't hold on big
    > monitors or dual views.
    >
    > I can't come up with any other reason that those 2 I mentioned.
    >
    > Cheers,
    > Tom Pester
    >
    >
    >> "tom pester" <> wrote in message
    >> news:...
    >>
    >>> I like my code and functions inside the aspx page itself unless the
    >>> project architecture tells you otherwise.
    >>> If you develop in a small team the separion isn't necessary and VWD
    >>> now
    >>> has full intellisense support for this scenario.
    >>> The fact that you can't have pure html in a function annoyed me very
    >>> much
    >>> too when coming from cASP but you get used to it.
    >>> I think they made it impossible for performance reasons cause mixing
    >>> code
    >>> with HTML did have a noticable negative perfermance effect.
    >>> Maybe they wanted to eliminate a bad programming practice?
    >>> Cheers,
    >>> Tom Pester
    >>>> Who says you can't have methods in the page?
    >>>>
    >>>> Just put your methods in <script runat="server"></server"
    >>>>
    >>>> And as someone mentioned, even though you can do this, you
    >>>> shouldn't. There is no reason you can't put it in a code behind
    >>>> file, or in a class library DLL.
    >>>>
    >>>> "John Rivers" <> wrote in message
    >>>> news:...
    >>>>
    >>>>> Hello,
    >>>>>
    >>>>> What good reason there is for not allowing methods in ASPX pages I
    >>>>> can't imagine, but here is how to get around that limitation:
    >>>>>
    >>>>> (START)
    >>>>> <body MS_POSITIONING="FlowLayout">
    >>>>> <form id="Form1" method="post" runat="server">
    >>>>> <%
    >>>>> MyMethod(__output);
    >>>>> %>
    >>>>> </form>
    >>>>> </body>
    >>>>> </html>
    >>>>> <%
    >>>>> }
    >>>>> void MyMethod(System.Web.UI.HtmlTextWriter __output) {
    >>>>> %><input type="text" name="Name" value="some html"/><%
    >>>>> %>
    >>>>> (END)
    >>>>> how this works:
    >>>>> ASP.NET takes your ASPX code and inserts it into a hidden Render
    >>>>> method that takes HtmlTextWriter as an argument
    >>>>>
    >>>>> we use "}" to close the current render method
    >>>>> then declare a method that takes the same argument
    >>>>> we don't need to put a closing brace because ASP.NET will
    >>>>> do that for us

    >
    >
     
    Marina, Aug 23, 2005
    #9
  10. John Rivers

    tom pester Guest

    Hi Marina,

    > I find the 2 arguments you listed more then enough to support the
    > reasons for doing it. Except with the change, that it more the
    > promotes thinking about these 2 things as separate. There is a lot to
    > be said from separating your UI from the business logic.


    I am all for the seperation of logic and presentation and business logic
    should defenetily go into its own space regardless of how small the project
    is.
    But the little code you write for wiring things up, ie that are specific
    to the GUI, don't need seperation cause its specific and thus not reasuable.

    A function that gets all orders from a database should be in a class library
    (and I mean not code behind).
    IMO A function that wires up the result to a datagrid doesn't have to be
    in a class.

    BTW Everything in ASP.NET is a class. The aspx file too. It gets transformed
    by a parser to a plain class :

    http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    http://dotnetdan.com/articles/aspnet/DataBinding.htm

    So by that rational I do everything in a class file so I must be doing it
    right ;)

    > And sorry, but your reasons for not doing just don't make sense to me.
    > I don't care if I have 100 files or 50 files. You still just see one
    > icon in VS, and you can either go to design view, or you can go to
    > code. You don't see twice as many files - so who cares if in reality
    > there are?


    I hear you but I like to keep everything KISS. So there must be a _good_
    reason if I have to double the project in files.

    > In any case, microsoft didn't limit anyone to any one model of how
    > things should be done. If this way works for you, go ahead.


    The arguments you make are all solid but for me the separation between markup
    and wire up code (not Business Logic) is a logical one.
    You can make it a physical separition by splitting the file in 2. But what
    does it give you? IMO not more power, except for the 2 reasons that are only
    a consequence of making it physical.

    Cheers,
    Tom Peste
     
    tom pester, Aug 23, 2005
    #10
  11. I don't have solid "evidence" of coding one way or the other. In most
    instances, it's simply user preference. The framework handles both the same
    way (ok there are a few differences, but not really). You can precompile your
    pages and you can compile the code-behind.

    I didn't come from classic ASP so I can't speak for someone's been used to
    having "inline" code. So I personally like the separation that code-behind
    provides. And I'm not using v2 of the VS and if it provides better
    editing/debugging capabilities, then that's great. This is one reason I
    haven't done my hard-core coding on the page itself because it has
    Intellisense, better debugging, etc.

    As for Mr. Rivers' complaint about ASP.NET in general as compared to ASP, he
    seems to be one who's more impressed by how fast (see his "VS.NET is 10 times
    slower than VB6" rant) or how pretty his code is, rather than the technology
    advantages ASP.NET and the .NET framework provide. A rather sophomoric
    complaint if you ask me. He should roll up his sleaves and look at the
    technology. I would hope he'd never go back to the primitive world of VB6/ASP
    if he understood the Framework better.

    Bottom line, if you like coding on your page, great. If you like
    code-behind, great.
    Remember, however, if you're on a development team, pick one or the other.
    Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've been
    involved in projects where there's been a mixture and it can be confusing
    going from one to the other and from an architecture standpoint, it's not
    good practice.

    -- John Harcourt

    "tom pester" wrote:

    > Hi Marina,
    >
    > > I find the 2 arguments you listed more then enough to support the
    > > reasons for doing it. Except with the change, that it more the
    > > promotes thinking about these 2 things as separate. There is a lot to
    > > be said from separating your UI from the business logic.

    >
    > I am all for the seperation of logic and presentation and business logic
    > should defenetily go into its own space regardless of how small the project
    > is.
    > But the little code you write for wiring things up, ie that are specific
    > to the GUI, don't need seperation cause its specific and thus not reasuable.
    >
    > A function that gets all orders from a database should be in a class library
    > (and I mean not code behind).
    > IMO A function that wires up the result to a datagrid doesn't have to be
    > in a class.
    >
    > BTW Everything in ASP.NET is a class. The aspx file too. It gets transformed
    > by a parser to a plain class :
    >
    > http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    > http://dotnetdan.com/articles/aspnet/DataBinding.htm
    >
    > So by that rational I do everything in a class file so I must be doing it
    > right ;)
    >
    > > And sorry, but your reasons for not doing just don't make sense to me.
    > > I don't care if I have 100 files or 50 files. You still just see one
    > > icon in VS, and you can either go to design view, or you can go to
    > > code. You don't see twice as many files - so who cares if in reality
    > > there are?

    >
    > I hear you but I like to keep everything KISS. So there must be a _good_
    > reason if I have to double the project in files.
    >
    > > In any case, microsoft didn't limit anyone to any one model of how
    > > things should be done. If this way works for you, go ahead.

    >
    > The arguments you make are all solid but for me the separation between markup
    > and wire up code (not Business Logic) is a logical one.
    > You can make it a physical separition by splitting the file in 2. But what
    > does it give you? IMO not more power, except for the 2 reasons that are only
    > a consequence of making it physical.
    >
    > Cheers,
    > Tom Pester
    >
    >
    >
     
    =?Utf-8?B?Sm9obiBIYXJjb3VydA==?=, Aug 25, 2005
    #11
  12. > Bottom line, if you like coding on your page, great. If you like
    > code-behind, great.
    > Remember, however, if you're on a development team, pick one or the other.
    > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > been
    > involved in projects where there's been a mixture and it can be confusing
    > going from one to the other and from an architecture standpoint, it's not
    > good practice.


    The real bottom line is, if you are serious about making a living as a
    developer, adopt best practices. They are called "best practices" because
    they improve the performance of the developer, and the performance,
    scalability, and maintainability of the software that the developer creates.
    Best practices are arrived at by experienced developers who have observed
    the problems and pitfalls of various methodologies, both by their own
    experiences, and by observing the experiences of others, over a long period
    of time.

    I was once told that "wisdom comes by experience, and experience by lack of
    wisdom." However, the older I get, I realize that there is another better
    way to come by wisdom, and that is by listening to those who already have
    it.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Paranoia is just a state of mind.

    "John Harcourt" <> wrote in message
    news:...
    >I don't have solid "evidence" of coding one way or the other. In most
    > instances, it's simply user preference. The framework handles both the
    > same
    > way (ok there are a few differences, but not really). You can precompile
    > your
    > pages and you can compile the code-behind.
    >
    > I didn't come from classic ASP so I can't speak for someone's been used to
    > having "inline" code. So I personally like the separation that code-behind
    > provides. And I'm not using v2 of the VS and if it provides better
    > editing/debugging capabilities, then that's great. This is one reason I
    > haven't done my hard-core coding on the page itself because it has
    > Intellisense, better debugging, etc.
    >
    > As for Mr. Rivers' complaint about ASP.NET in general as compared to ASP,
    > he
    > seems to be one who's more impressed by how fast (see his "VS.NET is 10
    > times
    > slower than VB6" rant) or how pretty his code is, rather than the
    > technology
    > advantages ASP.NET and the .NET framework provide. A rather sophomoric
    > complaint if you ask me. He should roll up his sleaves and look at the
    > technology. I would hope he'd never go back to the primitive world of
    > VB6/ASP
    > if he understood the Framework better.
    >
    > Bottom line, if you like coding on your page, great. If you like
    > code-behind, great.
    > Remember, however, if you're on a development team, pick one or the other.
    > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > been
    > involved in projects where there's been a mixture and it can be confusing
    > going from one to the other and from an architecture standpoint, it's not
    > good practice.
    >
    > -- John Harcourt
    >
    > "tom pester" wrote:
    >
    >> Hi Marina,
    >>
    >> > I find the 2 arguments you listed more then enough to support the
    >> > reasons for doing it. Except with the change, that it more the
    >> > promotes thinking about these 2 things as separate. There is a lot to
    >> > be said from separating your UI from the business logic.

    >>
    >> I am all for the seperation of logic and presentation and business logic
    >> should defenetily go into its own space regardless of how small the
    >> project
    >> is.
    >> But the little code you write for wiring things up, ie that are specific
    >> to the GUI, don't need seperation cause its specific and thus not
    >> reasuable.
    >>
    >> A function that gets all orders from a database should be in a class
    >> library
    >> (and I mean not code behind).
    >> IMO A function that wires up the result to a datagrid doesn't have to be
    >> in a class.
    >>
    >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    >> transformed
    >> by a parser to a plain class :
    >>
    >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    >>
    >> So by that rational I do everything in a class file so I must be doing it
    >> right ;)
    >>
    >> > And sorry, but your reasons for not doing just don't make sense to me.
    >> > I don't care if I have 100 files or 50 files. You still just see one
    >> > icon in VS, and you can either go to design view, or you can go to
    >> > code. You don't see twice as many files - so who cares if in reality
    >> > there are?

    >>
    >> I hear you but I like to keep everything KISS. So there must be a _good_
    >> reason if I have to double the project in files.
    >>
    >> > In any case, microsoft didn't limit anyone to any one model of how
    >> > things should be done. If this way works for you, go ahead.

    >>
    >> The arguments you make are all solid but for me the separation between
    >> markup
    >> and wire up code (not Business Logic) is a logical one.
    >> You can make it a physical separition by splitting the file in 2. But
    >> what
    >> does it give you? IMO not more power, except for the 2 reasons that are
    >> only
    >> a consequence of making it physical.
    >>
    >> Cheers,
    >> Tom Pester
    >>
    >>
    >>
     
    Kevin Spencer, Aug 26, 2005
    #12
  13. John Rivers

    John Rivers Guest

    who has it?

    why not me?

    big chunks of what is in asp.net today

    i wrote myself in vb6 for asp about 8 years ago

    code blocks aren't evil, they are the most intelligent
    way of handling html literals in presentation logic

    whether pre compiled or jit compiled, in methods, classes, controls
    or anything you like










    Kevin Spencer wrote:
    > > Bottom line, if you like coding on your page, great. If you like
    > > code-behind, great.
    > > Remember, however, if you're on a development team, pick one or the other.
    > > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > > been
    > > involved in projects where there's been a mixture and it can be confusing
    > > going from one to the other and from an architecture standpoint, it's not
    > > good practice.

    >
    > The real bottom line is, if you are serious about making a living as a
    > developer, adopt best practices. They are called "best practices" because
    > they improve the performance of the developer, and the performance,
    > scalability, and maintainability of the software that the developer creates.
    > Best practices are arrived at by experienced developers who have observed
    > the problems and pitfalls of various methodologies, both by their own
    > experiences, and by observing the experiences of others, over a long period
    > of time.
    >
    > I was once told that "wisdom comes by experience, and experience by lack of
    > wisdom." However, the older I get, I realize that there is another better
    > way to come by wisdom, and that is by listening to those who already have
    > it.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > Paranoia is just a state of mind.
    >
    > "John Harcourt" <> wrote in message
    > news:...
    > >I don't have solid "evidence" of coding one way or the other. In most
    > > instances, it's simply user preference. The framework handles both the
    > > same
    > > way (ok there are a few differences, but not really). You can precompile
    > > your
    > > pages and you can compile the code-behind.
    > >
    > > I didn't come from classic ASP so I can't speak for someone's been used to
    > > having "inline" code. So I personally like the separation that code-behind
    > > provides. And I'm not using v2 of the VS and if it provides better
    > > editing/debugging capabilities, then that's great. This is one reason I
    > > haven't done my hard-core coding on the page itself because it has
    > > Intellisense, better debugging, etc.
    > >
    > > As for Mr. Rivers' complaint about ASP.NET in general as compared to ASP,
    > > he
    > > seems to be one who's more impressed by how fast (see his "VS.NET is 10
    > > times
    > > slower than VB6" rant) or how pretty his code is, rather than the
    > > technology
    > > advantages ASP.NET and the .NET framework provide. A rather sophomoric
    > > complaint if you ask me. He should roll up his sleaves and look at the
    > > technology. I would hope he'd never go back to the primitive world of
    > > VB6/ASP
    > > if he understood the Framework better.
    > >
    > > Bottom line, if you like coding on your page, great. If you like
    > > code-behind, great.
    > > Remember, however, if you're on a development team, pick one or the other.
    > > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > > been
    > > involved in projects where there's been a mixture and it can be confusing
    > > going from one to the other and from an architecture standpoint, it's not
    > > good practice.
    > >
    > > -- John Harcourt
    > >
    > > "tom pester" wrote:
    > >
    > >> Hi Marina,
    > >>
    > >> > I find the 2 arguments you listed more then enough to support the
    > >> > reasons for doing it. Except with the change, that it more the
    > >> > promotes thinking about these 2 things as separate. There is a lot to
    > >> > be said from separating your UI from the business logic.
    > >>
    > >> I am all for the seperation of logic and presentation and business logic
    > >> should defenetily go into its own space regardless of how small the
    > >> project
    > >> is.
    > >> But the little code you write for wiring things up, ie that are specific
    > >> to the GUI, don't need seperation cause its specific and thus not
    > >> reasuable.
    > >>
    > >> A function that gets all orders from a database should be in a class
    > >> library
    > >> (and I mean not code behind).
    > >> IMO A function that wires up the result to a datagrid doesn't have to be
    > >> in a class.
    > >>
    > >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    > >> transformed
    > >> by a parser to a plain class :
    > >>
    > >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    > >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    > >>
    > >> So by that rational I do everything in a class file so I must be doing it
    > >> right ;)
    > >>
    > >> > And sorry, but your reasons for not doing just don't make sense to me.
    > >> > I don't care if I have 100 files or 50 files. You still just see one
    > >> > icon in VS, and you can either go to design view, or you can go to
    > >> > code. You don't see twice as many files - so who cares if in reality
    > >> > there are?
    > >>
    > >> I hear you but I like to keep everything KISS. So there must be a _good_
    > >> reason if I have to double the project in files.
    > >>
    > >> > In any case, microsoft didn't limit anyone to any one model of how
    > >> > things should be done. If this way works for you, go ahead.
    > >>
    > >> The arguments you make are all solid but for me the separation between
    > >> markup
    > >> and wire up code (not Business Logic) is a logical one.
    > >> You can make it a physical separition by splitting the file in 2. But
    > >> what
    > >> does it give you? IMO not more power, except for the 2 reasons that are
    > >> only
    > >> a consequence of making it physical.
    > >>
    > >> Cheers,
    > >> Tom Pester
    > >>
    > >>
    > >>
     
    John Rivers, Aug 27, 2005
    #13
  14. > who has it?

    People who have diligently sought it for many years. People who can accept
    painful truth, especially about themselves, and who are willing to change in
    response to those truths.

    > why not me?


    No reason whatsoever. The sooner you get started seeking it, the sooner you
    will find it. but it takes a great deal of time, patience, and persistence.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Paranoia is just a state of mind.

    "John Rivers" <> wrote in message
    news:...
    >
    >
    >
    >
    > who has it?
    >
    > why not me?
    >
    > big chunks of what is in asp.net today
    >
    > i wrote myself in vb6 for asp about 8 years ago
    >
    > code blocks aren't evil, they are the most intelligent
    > way of handling html literals in presentation logic
    >
    > whether pre compiled or jit compiled, in methods, classes, controls
    > or anything you like
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > Kevin Spencer wrote:
    >> > Bottom line, if you like coding on your page, great. If you like
    >> > code-behind, great.
    >> > Remember, however, if you're on a development team, pick one or the
    >> > other.
    >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    >> > been
    >> > involved in projects where there's been a mixture and it can be
    >> > confusing
    >> > going from one to the other and from an architecture standpoint, it's
    >> > not
    >> > good practice.

    >>
    >> The real bottom line is, if you are serious about making a living as a
    >> developer, adopt best practices. They are called "best practices" because
    >> they improve the performance of the developer, and the performance,
    >> scalability, and maintainability of the software that the developer
    >> creates.
    >> Best practices are arrived at by experienced developers who have observed
    >> the problems and pitfalls of various methodologies, both by their own
    >> experiences, and by observing the experiences of others, over a long
    >> period
    >> of time.
    >>
    >> I was once told that "wisdom comes by experience, and experience by lack
    >> of
    >> wisdom." However, the older I get, I realize that there is another better
    >> way to come by wisdom, and that is by listening to those who already have
    >> it.
    >>
    >> --
    >> HTH,
    >>
    >> Kevin Spencer
    >> Microsoft MVP
    >> .Net Developer
    >> Paranoia is just a state of mind.
    >>
    >> "John Harcourt" <> wrote in message
    >> news:...
    >> >I don't have solid "evidence" of coding one way or the other. In most
    >> > instances, it's simply user preference. The framework handles both the
    >> > same
    >> > way (ok there are a few differences, but not really). You can
    >> > precompile
    >> > your
    >> > pages and you can compile the code-behind.
    >> >
    >> > I didn't come from classic ASP so I can't speak for someone's been used
    >> > to
    >> > having "inline" code. So I personally like the separation that
    >> > code-behind
    >> > provides. And I'm not using v2 of the VS and if it provides better
    >> > editing/debugging capabilities, then that's great. This is one reason I
    >> > haven't done my hard-core coding on the page itself because it has
    >> > Intellisense, better debugging, etc.
    >> >
    >> > As for Mr. Rivers' complaint about ASP.NET in general as compared to
    >> > ASP,
    >> > he
    >> > seems to be one who's more impressed by how fast (see his "VS.NET is 10
    >> > times
    >> > slower than VB6" rant) or how pretty his code is, rather than the
    >> > technology
    >> > advantages ASP.NET and the .NET framework provide. A rather sophomoric
    >> > complaint if you ask me. He should roll up his sleaves and look at the
    >> > technology. I would hope he'd never go back to the primitive world of
    >> > VB6/ASP
    >> > if he understood the Framework better.
    >> >
    >> > Bottom line, if you like coding on your page, great. If you like
    >> > code-behind, great.
    >> > Remember, however, if you're on a development team, pick one or the
    >> > other.
    >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    >> > been
    >> > involved in projects where there's been a mixture and it can be
    >> > confusing
    >> > going from one to the other and from an architecture standpoint, it's
    >> > not
    >> > good practice.
    >> >
    >> > -- John Harcourt
    >> >
    >> > "tom pester" wrote:
    >> >
    >> >> Hi Marina,
    >> >>
    >> >> > I find the 2 arguments you listed more then enough to support the
    >> >> > reasons for doing it. Except with the change, that it more the
    >> >> > promotes thinking about these 2 things as separate. There is a lot
    >> >> > to
    >> >> > be said from separating your UI from the business logic.
    >> >>
    >> >> I am all for the seperation of logic and presentation and business
    >> >> logic
    >> >> should defenetily go into its own space regardless of how small the
    >> >> project
    >> >> is.
    >> >> But the little code you write for wiring things up, ie that are
    >> >> specific
    >> >> to the GUI, don't need seperation cause its specific and thus not
    >> >> reasuable.
    >> >>
    >> >> A function that gets all orders from a database should be in a class
    >> >> library
    >> >> (and I mean not code behind).
    >> >> IMO A function that wires up the result to a datagrid doesn't have to
    >> >> be
    >> >> in a class.
    >> >>
    >> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    >> >> transformed
    >> >> by a parser to a plain class :
    >> >>
    >> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    >> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    >> >>
    >> >> So by that rational I do everything in a class file so I must be doing
    >> >> it
    >> >> right ;)
    >> >>
    >> >> > And sorry, but your reasons for not doing just don't make sense to
    >> >> > me.
    >> >> > I don't care if I have 100 files or 50 files. You still just see
    >> >> > one
    >> >> > icon in VS, and you can either go to design view, or you can go to
    >> >> > code. You don't see twice as many files - so who cares if in
    >> >> > reality
    >> >> > there are?
    >> >>
    >> >> I hear you but I like to keep everything KISS. So there must be a
    >> >> _good_
    >> >> reason if I have to double the project in files.
    >> >>
    >> >> > In any case, microsoft didn't limit anyone to any one model of how
    >> >> > things should be done. If this way works for you, go ahead.
    >> >>
    >> >> The arguments you make are all solid but for me the separation between
    >> >> markup
    >> >> and wire up code (not Business Logic) is a logical one.
    >> >> You can make it a physical separition by splitting the file in 2. But
    >> >> what
    >> >> does it give you? IMO not more power, except for the 2 reasons that
    >> >> are
    >> >> only
    >> >> a consequence of making it physical.
    >> >>
    >> >> Cheers,
    >> >> Tom Pester
    >> >>
    >> >>
    >> >>

    >
     
    Kevin Spencer, Aug 29, 2005
    #14
  15. No argument from me there.
    With the subject of code-behind, however, Best Practices indicate that the
    size and scope of a project that you're dealing (and the developers) with can
    help determine if you should use code-behind or not. MS didn't stop the
    ability from writing in-line code. Many of the early .NET books (even from
    MSPress) hardly mentioned code-behind at all. MS's own Matrix tool doesn't
    support code-behind. So I can hardly be surprised to see hoards of
    professional developers following Best Practices as they know it, but not
    using code-behind. Totally legitimate.
    From a personal level I've always used code-behind, even for small pages. I
    just like the separation it provides. But I have a good buddy who wrote ASP
    classic for years and finds code-behind a bit getting used to. His first
    instinct is to write in-line code.

    cheers.

    "Kevin Spencer" wrote:

    > > Bottom line, if you like coding on your page, great. If you like
    > > code-behind, great.
    > > Remember, however, if you're on a development team, pick one or the other.
    > > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > > been
    > > involved in projects where there's been a mixture and it can be confusing
    > > going from one to the other and from an architecture standpoint, it's not
    > > good practice.

    >
    > The real bottom line is, if you are serious about making a living as a
    > developer, adopt best practices. They are called "best practices" because
    > they improve the performance of the developer, and the performance,
    > scalability, and maintainability of the software that the developer creates.
    > Best practices are arrived at by experienced developers who have observed
    > the problems and pitfalls of various methodologies, both by their own
    > experiences, and by observing the experiences of others, over a long period
    > of time.
    >
    > I was once told that "wisdom comes by experience, and experience by lack of
    > wisdom." However, the older I get, I realize that there is another better
    > way to come by wisdom, and that is by listening to those who already have
    > it.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > ..Net Developer
    > Paranoia is just a state of mind.
    >
    > "John Harcourt" <> wrote in message
    > news:...
    > >I don't have solid "evidence" of coding one way or the other. In most
    > > instances, it's simply user preference. The framework handles both the
    > > same
    > > way (ok there are a few differences, but not really). You can precompile
    > > your
    > > pages and you can compile the code-behind.
    > >
    > > I didn't come from classic ASP so I can't speak for someone's been used to
    > > having "inline" code. So I personally like the separation that code-behind
    > > provides. And I'm not using v2 of the VS and if it provides better
    > > editing/debugging capabilities, then that's great. This is one reason I
    > > haven't done my hard-core coding on the page itself because it has
    > > Intellisense, better debugging, etc.
    > >
    > > As for Mr. Rivers' complaint about ASP.NET in general as compared to ASP,
    > > he
    > > seems to be one who's more impressed by how fast (see his "VS.NET is 10
    > > times
    > > slower than VB6" rant) or how pretty his code is, rather than the
    > > technology
    > > advantages ASP.NET and the .NET framework provide. A rather sophomoric
    > > complaint if you ask me. He should roll up his sleaves and look at the
    > > technology. I would hope he'd never go back to the primitive world of
    > > VB6/ASP
    > > if he understood the Framework better.
    > >
    > > Bottom line, if you like coding on your page, great. If you like
    > > code-behind, great.
    > > Remember, however, if you're on a development team, pick one or the other.
    > > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > > been
    > > involved in projects where there's been a mixture and it can be confusing
    > > going from one to the other and from an architecture standpoint, it's not
    > > good practice.
    > >
    > > -- John Harcourt
    > >
    > > "tom pester" wrote:
    > >
    > >> Hi Marina,
    > >>
    > >> > I find the 2 arguments you listed more then enough to support the
    > >> > reasons for doing it. Except with the change, that it more the
    > >> > promotes thinking about these 2 things as separate. There is a lot to
    > >> > be said from separating your UI from the business logic.
    > >>
    > >> I am all for the seperation of logic and presentation and business logic
    > >> should defenetily go into its own space regardless of how small the
    > >> project
    > >> is.
    > >> But the little code you write for wiring things up, ie that are specific
    > >> to the GUI, don't need seperation cause its specific and thus not
    > >> reasuable.
    > >>
    > >> A function that gets all orders from a database should be in a class
    > >> library
    > >> (and I mean not code behind).
    > >> IMO A function that wires up the result to a datagrid doesn't have to be
    > >> in a class.
    > >>
    > >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    > >> transformed
    > >> by a parser to a plain class :
    > >>
    > >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    > >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    > >>
    > >> So by that rational I do everything in a class file so I must be doing it
    > >> right ;)
    > >>
    > >> > And sorry, but your reasons for not doing just don't make sense to me.
    > >> > I don't care if I have 100 files or 50 files. You still just see one
    > >> > icon in VS, and you can either go to design view, or you can go to
    > >> > code. You don't see twice as many files - so who cares if in reality
    > >> > there are?
    > >>
    > >> I hear you but I like to keep everything KISS. So there must be a _good_
    > >> reason if I have to double the project in files.
    > >>
    > >> > In any case, microsoft didn't limit anyone to any one model of how
    > >> > things should be done. If this way works for you, go ahead.
    > >>
    > >> The arguments you make are all solid but for me the separation between
    > >> markup
    > >> and wire up code (not Business Logic) is a logical one.
    > >> You can make it a physical separition by splitting the file in 2. But
    > >> what
    > >> does it give you? IMO not more power, except for the 2 reasons that are
    > >> only
    > >> a consequence of making it physical.
    > >>
    > >> Cheers,
    > >> Tom Pester
    > >>
    > >>
    > >>

    >
    >
    >
     
    =?Utf-8?B?Sm9obiBIYXJjb3VydA==?=, Aug 29, 2005
    #15
  16. Hi John,

    As far as CodeBehind is concerned, I am not aware of any significant
    differences in the use of it versus not using it. The CodeBehind class logic
    can be in the same file as the Template code and still be separated from it
    (all at the top, for example). I feel that the most important "Best
    Practices" consideration regarding Pages is that Pages should not contain
    any business logic, only interface logic.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Paranoia is just a state of mind.

    "John Harcourt" <> wrote in message
    news:...
    > No argument from me there.
    > With the subject of code-behind, however, Best Practices indicate that the
    > size and scope of a project that you're dealing (and the developers) with
    > can
    > help determine if you should use code-behind or not. MS didn't stop the
    > ability from writing in-line code. Many of the early .NET books (even from
    > MSPress) hardly mentioned code-behind at all. MS's own Matrix tool doesn't
    > support code-behind. So I can hardly be surprised to see hoards of
    > professional developers following Best Practices as they know it, but not
    > using code-behind. Totally legitimate.
    > From a personal level I've always used code-behind, even for small pages.
    > I
    > just like the separation it provides. But I have a good buddy who wrote
    > ASP
    > classic for years and finds code-behind a bit getting used to. His first
    > instinct is to write in-line code.
    >
    > cheers.
    >
    > "Kevin Spencer" wrote:
    >
    >> > Bottom line, if you like coding on your page, great. If you like
    >> > code-behind, great.
    >> > Remember, however, if you're on a development team, pick one or the
    >> > other.
    >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    >> > been
    >> > involved in projects where there's been a mixture and it can be
    >> > confusing
    >> > going from one to the other and from an architecture standpoint, it's
    >> > not
    >> > good practice.

    >>
    >> The real bottom line is, if you are serious about making a living as a
    >> developer, adopt best practices. They are called "best practices" because
    >> they improve the performance of the developer, and the performance,
    >> scalability, and maintainability of the software that the developer
    >> creates.
    >> Best practices are arrived at by experienced developers who have observed
    >> the problems and pitfalls of various methodologies, both by their own
    >> experiences, and by observing the experiences of others, over a long
    >> period
    >> of time.
    >>
    >> I was once told that "wisdom comes by experience, and experience by lack
    >> of
    >> wisdom." However, the older I get, I realize that there is another better
    >> way to come by wisdom, and that is by listening to those who already have
    >> it.
    >>
    >> --
    >> HTH,
    >>
    >> Kevin Spencer
    >> Microsoft MVP
    >> ..Net Developer
    >> Paranoia is just a state of mind.
    >>
    >> "John Harcourt" <> wrote in message
    >> news:...
    >> >I don't have solid "evidence" of coding one way or the other. In most
    >> > instances, it's simply user preference. The framework handles both the
    >> > same
    >> > way (ok there are a few differences, but not really). You can
    >> > precompile
    >> > your
    >> > pages and you can compile the code-behind.
    >> >
    >> > I didn't come from classic ASP so I can't speak for someone's been used
    >> > to
    >> > having "inline" code. So I personally like the separation that
    >> > code-behind
    >> > provides. And I'm not using v2 of the VS and if it provides better
    >> > editing/debugging capabilities, then that's great. This is one reason I
    >> > haven't done my hard-core coding on the page itself because it has
    >> > Intellisense, better debugging, etc.
    >> >
    >> > As for Mr. Rivers' complaint about ASP.NET in general as compared to
    >> > ASP,
    >> > he
    >> > seems to be one who's more impressed by how fast (see his "VS.NET is 10
    >> > times
    >> > slower than VB6" rant) or how pretty his code is, rather than the
    >> > technology
    >> > advantages ASP.NET and the .NET framework provide. A rather sophomoric
    >> > complaint if you ask me. He should roll up his sleaves and look at the
    >> > technology. I would hope he'd never go back to the primitive world of
    >> > VB6/ASP
    >> > if he understood the Framework better.
    >> >
    >> > Bottom line, if you like coding on your page, great. If you like
    >> > code-behind, great.
    >> > Remember, however, if you're on a development team, pick one or the
    >> > other.
    >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    >> > been
    >> > involved in projects where there's been a mixture and it can be
    >> > confusing
    >> > going from one to the other and from an architecture standpoint, it's
    >> > not
    >> > good practice.
    >> >
    >> > -- John Harcourt
    >> >
    >> > "tom pester" wrote:
    >> >
    >> >> Hi Marina,
    >> >>
    >> >> > I find the 2 arguments you listed more then enough to support the
    >> >> > reasons for doing it. Except with the change, that it more the
    >> >> > promotes thinking about these 2 things as separate. There is a lot
    >> >> > to
    >> >> > be said from separating your UI from the business logic.
    >> >>
    >> >> I am all for the seperation of logic and presentation and business
    >> >> logic
    >> >> should defenetily go into its own space regardless of how small the
    >> >> project
    >> >> is.
    >> >> But the little code you write for wiring things up, ie that are
    >> >> specific
    >> >> to the GUI, don't need seperation cause its specific and thus not
    >> >> reasuable.
    >> >>
    >> >> A function that gets all orders from a database should be in a class
    >> >> library
    >> >> (and I mean not code behind).
    >> >> IMO A function that wires up the result to a datagrid doesn't have to
    >> >> be
    >> >> in a class.
    >> >>
    >> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    >> >> transformed
    >> >> by a parser to a plain class :
    >> >>
    >> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    >> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    >> >>
    >> >> So by that rational I do everything in a class file so I must be doing
    >> >> it
    >> >> right ;)
    >> >>
    >> >> > And sorry, but your reasons for not doing just don't make sense to
    >> >> > me.
    >> >> > I don't care if I have 100 files or 50 files. You still just see
    >> >> > one
    >> >> > icon in VS, and you can either go to design view, or you can go to
    >> >> > code. You don't see twice as many files - so who cares if in
    >> >> > reality
    >> >> > there are?
    >> >>
    >> >> I hear you but I like to keep everything KISS. So there must be a
    >> >> _good_
    >> >> reason if I have to double the project in files.
    >> >>
    >> >> > In any case, microsoft didn't limit anyone to any one model of how
    >> >> > things should be done. If this way works for you, go ahead.
    >> >>
    >> >> The arguments you make are all solid but for me the separation between
    >> >> markup
    >> >> and wire up code (not Business Logic) is a logical one.
    >> >> You can make it a physical separition by splitting the file in 2. But
    >> >> what
    >> >> does it give you? IMO not more power, except for the 2 reasons that
    >> >> are
    >> >> only
    >> >> a consequence of making it physical.
    >> >>
    >> >> Cheers,
    >> >> Tom Pester
    >> >>
    >> >>
    >> >>

    >>
    >>
    >>
     
    Kevin Spencer, Aug 29, 2005
    #16
  17. John Rivers

    John Horst Guest

    If I understand it right, there is a compilation difference between
    inline and codebehind. I do know that you can change inline code
    without having to redploy the binary in the bin folder. That might look
    good from one view, but seems to come at a performance cost.

    As for all the books out there, most have been written on a marketing
    assumption that the reader may not have VS (thus they use inline samples
    and do not show the user how to make the most of the VS IDE). I think
    that assumption is probably largely wrong.

    John

    -----Original Message-----
    From: Kevin Spencer [mailto:]
    Posted At: Monday, August 29, 2005 8:55 AM
    Posted To: microsoft.public.dotnet.framework.aspnet
    Conversation: TRICK: methods in ASPX pages with <%%> code blocks
    Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks


    Hi John,

    As far as CodeBehind is concerned, I am not aware of any significant
    differences in the use of it versus not using it. The CodeBehind class
    logic can be in the same file as the Template code and still be
    separated from it (all at the top, for example). I feel that the most
    important "Best Practices" consideration regarding Pages is that Pages
    should not contain any business logic, only interface logic.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Paranoia is just a state of mind.

    "John Harcourt" <> wrote in
    message news:...
    > No argument from me there.
    > With the subject of code-behind, however, Best Practices indicate that


    > the size and scope of a project that you're dealing (and the
    > developers) with can help determine if you should use code-behind or
    > not. MS didn't stop the ability from writing in-line code. Many of
    > the early .NET books (even from
    > MSPress) hardly mentioned code-behind at all. MS's own Matrix tool
    > doesn't support code-behind. So I can hardly be surprised to see
    > hoards of professional developers following Best Practices as they
    > know it, but not using code-behind. Totally legitimate.
    > From a personal level I've always used code-behind, even for small

    pages.
    > I
    > just like the separation it provides. But I have a good buddy who
    > wrote ASP classic for years and finds code-behind a bit getting used
    > to. His first instinct is to write in-line code.
    >
    > cheers.
    >
    > "Kevin Spencer" wrote:
    >
    >> > Bottom line, if you like coding on your page, great. If you like
    >> > code-behind, great.
    >> > Remember, however, if you're on a development team, pick one or the


    >> > other.
    >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it.
    >> > I've been involved in projects where there's been a mixture and it
    >> > can be confusing going from one to the other and from an
    >> > architecture standpoint, it's not good practice.

    >>
    >> The real bottom line is, if you are serious about making a living as
    >> a developer, adopt best practices. They are called "best practices"
    >> because they improve the performance of the developer, and the
    >> performance, scalability, and maintainability of the software that
    >> the developer creates.
    >> Best practices are arrived at by experienced developers who have
    >> observed the problems and pitfalls of various methodologies, both by
    >> their own experiences, and by observing the experiences of others,
    >> over a long period of time.
    >>
    >> I was once told that "wisdom comes by experience, and experience by
    >> lack of wisdom." However, the older I get, I realize that there is
    >> another better way to come by wisdom, and that is by listening to
    >> those who already have it.
    >>
    >> --
    >> HTH,
    >>
    >> Kevin Spencer
    >> Microsoft MVP
    >> ..Net Developer
    >> Paranoia is just a state of mind.
    >>
    >> "John Harcourt" <> wrote in
    >> message news:...
    >> >I don't have solid "evidence" of coding one way or the other. In
    >> >most instances, it's simply user preference. The framework handles
    >> >both the same way (ok there are a few differences, but not
    >> >really). You can precompile your pages and you can compile the
    >> >code-behind.
    >> >
    >> > I didn't come from classic ASP so I can't speak for someone's been
    >> > used to having "inline" code. So I personally like the separation
    >> > that code-behind provides. And I'm not using v2 of the VS and if it


    >> > provides better editing/debugging capabilities, then that's great.
    >> > This is one reason I haven't done my hard-core coding on the page
    >> > itself because it has Intellisense, better debugging, etc.
    >> >
    >> > As for Mr. Rivers' complaint about ASP.NET in general as compared
    >> > to ASP, he seems to be one who's more impressed by how fast (see
    >> > his "VS.NET is 10 times slower than VB6" rant) or how pretty his
    >> > code is, rather than the technology advantages ASP.NET and the .NET


    >> > framework provide. A rather sophomoric complaint if you ask me. He
    >> > should roll up his sleaves and look at the technology. I would hope


    >> > he'd never go back to the primitive world of VB6/ASP if he
    >> > understood the Framework better.
    >> >
    >> > Bottom line, if you like coding on your page, great. If you like
    >> > code-behind, great.
    >> > Remember, however, if you're on a development team, pick one or the


    >> > other.
    >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it.
    >> > I've been involved in projects where there's been a mixture and it
    >> > can be confusing going from one to the other and from an
    >> > architecture standpoint, it's not good practice.
    >> >
    >> > -- John Harcourt
    >> >
    >> > "tom pester" wrote:
    >> >
    >> >> Hi Marina,
    >> >>
    >> >> > I find the 2 arguments you listed more then enough to support
    >> >> > the reasons for doing it. Except with the change, that it more
    >> >> > the promotes thinking about these 2 things as separate. There
    >> >> > is a lot to be said from separating your UI from the business
    >> >> > logic.
    >> >>
    >> >> I am all for the seperation of logic and presentation and business


    >> >> logic should defenetily go into its own space regardless of how
    >> >> small the project is.
    >> >> But the little code you write for wiring things up, ie that are
    >> >> specific to the GUI, don't need seperation cause its specific and
    >> >> thus not reasuable.
    >> >>
    >> >> A function that gets all orders from a database should be in a
    >> >> class library (and I mean not code behind).
    >> >> IMO A function that wires up the result to a datagrid doesn't have


    >> >> to be in a class.
    >> >>
    >> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    >> >> transformed by a parser to a plain class :
    >> >>
    >> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    >> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    >> >>
    >> >> So by that rational I do everything in a class file so I must be
    >> >> doing it right ;)
    >> >>
    >> >> > And sorry, but your reasons for not doing just don't make sense
    >> >> > to me.
    >> >> > I don't care if I have 100 files or 50 files. You still just
    >> >> > see one icon in VS, and you can either go to design view, or you


    >> >> > can go to code. You don't see twice as many files - so who
    >> >> > cares if in reality there are?
    >> >>
    >> >> I hear you but I like to keep everything KISS. So there must be a
    >> >> _good_ reason if I have to double the project in files.
    >> >>
    >> >> > In any case, microsoft didn't limit anyone to any one model of
    >> >> > how things should be done. If this way works for you, go ahead.
    >> >>
    >> >> The arguments you make are all solid but for me the separation
    >> >> between markup and wire up code (not Business Logic) is a logical
    >> >> one.
    >> >> You can make it a physical separition by splitting the file in 2.
    >> >> But what does it give you? IMO not more power, except for the 2
    >> >> reasons that are only a consequence of making it physical.
    >> >>
    >> >> Cheers,
    >> >> Tom Pester
    >> >>
    >> >>
    >> >>

    >>
    >>
    >>
     
    John Horst, Aug 29, 2005
    #17
  18. John Rivers

    John Rivers Guest

    Yes!
    Somebody understands at last.



    Kevin Spencer wrote:
    > Hi John,
    >
    > As far as CodeBehind is concerned, I am not aware of any significant
    > differences in the use of it versus not using it. The CodeBehind class logic
    > can be in the same file as the Template code and still be separated from it
    > (all at the top, for example). I feel that the most important "Best
    > Practices" consideration regarding Pages is that Pages should not contain
    > any business logic, only interface logic.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > Paranoia is just a state of mind.
    >
    > "John Harcourt" <> wrote in message
    > news:...
    > > No argument from me there.
    > > With the subject of code-behind, however, Best Practices indicate that the
    > > size and scope of a project that you're dealing (and the developers) with
    > > can
    > > help determine if you should use code-behind or not. MS didn't stop the
    > > ability from writing in-line code. Many of the early .NET books (even from
    > > MSPress) hardly mentioned code-behind at all. MS's own Matrix tool doesn't
    > > support code-behind. So I can hardly be surprised to see hoards of
    > > professional developers following Best Practices as they know it, but not
    > > using code-behind. Totally legitimate.
    > > From a personal level I've always used code-behind, even for small pages.
    > > I
    > > just like the separation it provides. But I have a good buddy who wrote
    > > ASP
    > > classic for years and finds code-behind a bit getting used to. His first
    > > instinct is to write in-line code.
    > >
    > > cheers.
    > >
    > > "Kevin Spencer" wrote:
    > >
    > >> > Bottom line, if you like coding on your page, great. If you like
    > >> > code-behind, great.
    > >> > Remember, however, if you're on a development team, pick one or the
    > >> > other.
    > >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > >> > been
    > >> > involved in projects where there's been a mixture and it can be
    > >> > confusing
    > >> > going from one to the other and from an architecture standpoint, it's
    > >> > not
    > >> > good practice.
    > >>
    > >> The real bottom line is, if you are serious about making a living as a
    > >> developer, adopt best practices. They are called "best practices" because
    > >> they improve the performance of the developer, and the performance,
    > >> scalability, and maintainability of the software that the developer
    > >> creates.
    > >> Best practices are arrived at by experienced developers who have observed
    > >> the problems and pitfalls of various methodologies, both by their own
    > >> experiences, and by observing the experiences of others, over a long
    > >> period
    > >> of time.
    > >>
    > >> I was once told that "wisdom comes by experience, and experience by lack
    > >> of
    > >> wisdom." However, the older I get, I realize that there is another better
    > >> way to come by wisdom, and that is by listening to those who already have
    > >> it.
    > >>
    > >> --
    > >> HTH,
    > >>
    > >> Kevin Spencer
    > >> Microsoft MVP
    > >> ..Net Developer
    > >> Paranoia is just a state of mind.
    > >>
    > >> "John Harcourt" <> wrote in message
    > >> news:...
    > >> >I don't have solid "evidence" of coding one way or the other. In most
    > >> > instances, it's simply user preference. The framework handles both the
    > >> > same
    > >> > way (ok there are a few differences, but not really). You can
    > >> > precompile
    > >> > your
    > >> > pages and you can compile the code-behind.
    > >> >
    > >> > I didn't come from classic ASP so I can't speak for someone's been used
    > >> > to
    > >> > having "inline" code. So I personally like the separation that
    > >> > code-behind
    > >> > provides. And I'm not using v2 of the VS and if it provides better
    > >> > editing/debugging capabilities, then that's great. This is one reason I
    > >> > haven't done my hard-core coding on the page itself because it has
    > >> > Intellisense, better debugging, etc.
    > >> >
    > >> > As for Mr. Rivers' complaint about ASP.NET in general as compared to
    > >> > ASP,
    > >> > he
    > >> > seems to be one who's more impressed by how fast (see his "VS.NET is 10
    > >> > times
    > >> > slower than VB6" rant) or how pretty his code is, rather than the
    > >> > technology
    > >> > advantages ASP.NET and the .NET framework provide. A rather sophomoric
    > >> > complaint if you ask me. He should roll up his sleaves and look at the
    > >> > technology. I would hope he'd never go back to the primitive world of
    > >> > VB6/ASP
    > >> > if he understood the Framework better.
    > >> >
    > >> > Bottom line, if you like coding on your page, great. If you like
    > >> > code-behind, great.
    > >> > Remember, however, if you're on a development team, pick one or the
    > >> > other.
    > >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
    > >> > been
    > >> > involved in projects where there's been a mixture and it can be
    > >> > confusing
    > >> > going from one to the other and from an architecture standpoint, it's
    > >> > not
    > >> > good practice.
    > >> >
    > >> > -- John Harcourt
    > >> >
    > >> > "tom pester" wrote:
    > >> >
    > >> >> Hi Marina,
    > >> >>
    > >> >> > I find the 2 arguments you listed more then enough to support the
    > >> >> > reasons for doing it. Except with the change, that it more the
    > >> >> > promotes thinking about these 2 things as separate. There is a lot
    > >> >> > to
    > >> >> > be said from separating your UI from the business logic.
    > >> >>
    > >> >> I am all for the seperation of logic and presentation and business
    > >> >> logic
    > >> >> should defenetily go into its own space regardless of how small the
    > >> >> project
    > >> >> is.
    > >> >> But the little code you write for wiring things up, ie that are
    > >> >> specific
    > >> >> to the GUI, don't need seperation cause its specific and thus not
    > >> >> reasuable.
    > >> >>
    > >> >> A function that gets all orders from a database should be in a class
    > >> >> library
    > >> >> (and I mean not code behind).
    > >> >> IMO A function that wires up the result to a datagrid doesn't have to
    > >> >> be
    > >> >> in a class.
    > >> >>
    > >> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    > >> >> transformed
    > >> >> by a parser to a plain class :
    > >> >>
    > >> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    > >> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    > >> >>
    > >> >> So by that rational I do everything in a class file so I must be doing
    > >> >> it
    > >> >> right ;)
    > >> >>
    > >> >> > And sorry, but your reasons for not doing just don't make sense to
    > >> >> > me.
    > >> >> > I don't care if I have 100 files or 50 files. You still just see
    > >> >> > one
    > >> >> > icon in VS, and you can either go to design view, or you can go to
    > >> >> > code. You don't see twice as many files - so who cares if in
    > >> >> > reality
    > >> >> > there are?
    > >> >>
    > >> >> I hear you but I like to keep everything KISS. So there must be a
    > >> >> _good_
    > >> >> reason if I have to double the project in files.
    > >> >>
    > >> >> > In any case, microsoft didn't limit anyone to any one model of how
    > >> >> > things should be done. If this way works for you, go ahead.
    > >> >>
    > >> >> The arguments you make are all solid but for me the separation between
    > >> >> markup
    > >> >> and wire up code (not Business Logic) is a logical one.
    > >> >> You can make it a physical separition by splitting the file in 2. But
    > >> >> what
    > >> >> does it give you? IMO not more power, except for the 2 reasons that
    > >> >> are
    > >> >> only
    > >> >> a consequence of making it physical.
    > >> >>
    > >> >> Cheers,
    > >> >> Tom Pester
    > >> >>
    > >> >>
    > >> >>
    > >>
    > >>
    > >>
     
    John Rivers, Aug 29, 2005
    #18
  19. John Rivers

    John Rivers Guest

    the difference between aspx and aspx.cs
    is straightforward

    aspx is jit compiled when the page is requested

    everytime the page is requested the asp.net runtime
    checks the modifydate and size of the file

    if it has changed it recompiles the new one

    this allows for designers to change aspx and upload
    it without recompilation

    that is a GOOD THING

    however, where ms has made a mistake is in VS.NET
    they should have allowed ASPX pages to be compiled
    as part of the BUILD, this would let structural errors
    be caught without a potentially long winded live test
    or worse, a customer having a problem

    thus allowing for, if required, fully compiled
    ASPX and don't let the designer interfere with
    production server

    the point is there is no actual performance
    difference between the two, code blocks are not evil.

    and if you subscribe to the idea that no html literals
    should be used by developers, thus enabling the
    automatic html versioning stuff to work (not that it will)
    you must continue that policy throughout your work, all
    classes you create that do generate html literals must take
    part in the html versioning infrastructure (like to see you
    try) and also solve the issue of html versioning in aspx
    (yeah, try that too!)

    so back to my original point

    WHY DID MICROSOFT FORCE ME TO STOP WRITING PRESENTATION CLASSES
    AND METHODS WITH HTML LITERALS (CODE BLOCKS)

    the answer: they have made an "ERROR IN JUDGEMENT" aka "A MISTAKE"




    John Horst wrote:
    > If I understand it right, there is a compilation difference between
    > inline and codebehind. I do know that you can change inline code
    > without having to redploy the binary in the bin folder. That might look
    > good from one view, but seems to come at a performance cost.
    >
    > As for all the books out there, most have been written on a marketing
    > assumption that the reader may not have VS (thus they use inline samples
    > and do not show the user how to make the most of the VS IDE). I think
    > that assumption is probably largely wrong.
    >
    > John
    >
    > -----Original Message-----
    > From: Kevin Spencer [mailto:]
    > Posted At: Monday, August 29, 2005 8:55 AM
    > Posted To: microsoft.public.dotnet.framework.aspnet
    > Conversation: TRICK: methods in ASPX pages with <%%> code blocks
    > Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks
    >
    >
    > Hi John,
    >
    > As far as CodeBehind is concerned, I am not aware of any significant
    > differences in the use of it versus not using it. The CodeBehind class
    > logic can be in the same file as the Template code and still be
    > separated from it (all at the top, for example). I feel that the most
    > important "Best Practices" consideration regarding Pages is that Pages
    > should not contain any business logic, only interface logic.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > Paranoia is just a state of mind.
    >
    > "John Harcourt" <> wrote in
    > message news:...
    > > No argument from me there.
    > > With the subject of code-behind, however, Best Practices indicate that

    >
    > > the size and scope of a project that you're dealing (and the
    > > developers) with can help determine if you should use code-behind or
    > > not. MS didn't stop the ability from writing in-line code. Many of
    > > the early .NET books (even from
    > > MSPress) hardly mentioned code-behind at all. MS's own Matrix tool
    > > doesn't support code-behind. So I can hardly be surprised to see
    > > hoards of professional developers following Best Practices as they
    > > know it, but not using code-behind. Totally legitimate.
    > > From a personal level I've always used code-behind, even for small

    > pages.
    > > I
    > > just like the separation it provides. But I have a good buddy who
    > > wrote ASP classic for years and finds code-behind a bit getting used
    > > to. His first instinct is to write in-line code.
    > >
    > > cheers.
    > >
    > > "Kevin Spencer" wrote:
    > >
    > >> > Bottom line, if you like coding on your page, great. If you like
    > >> > code-behind, great.
    > >> > Remember, however, if you're on a development team, pick one or the

    >
    > >> > other.
    > >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it.
    > >> > I've been involved in projects where there's been a mixture and it
    > >> > can be confusing going from one to the other and from an
    > >> > architecture standpoint, it's not good practice.
    > >>
    > >> The real bottom line is, if you are serious about making a living as
    > >> a developer, adopt best practices. They are called "best practices"
    > >> because they improve the performance of the developer, and the
    > >> performance, scalability, and maintainability of the software that
    > >> the developer creates.
    > >> Best practices are arrived at by experienced developers who have
    > >> observed the problems and pitfalls of various methodologies, both by
    > >> their own experiences, and by observing the experiences of others,
    > >> over a long period of time.
    > >>
    > >> I was once told that "wisdom comes by experience, and experience by
    > >> lack of wisdom." However, the older I get, I realize that there is
    > >> another better way to come by wisdom, and that is by listening to
    > >> those who already have it.
    > >>
    > >> --
    > >> HTH,
    > >>
    > >> Kevin Spencer
    > >> Microsoft MVP
    > >> ..Net Developer
    > >> Paranoia is just a state of mind.
    > >>
    > >> "John Harcourt" <> wrote in
    > >> message news:...
    > >> >I don't have solid "evidence" of coding one way or the other. In
    > >> >most instances, it's simply user preference. The framework handles
    > >> >both the same way (ok there are a few differences, but not
    > >> >really). You can precompile your pages and you can compile the
    > >> >code-behind.
    > >> >
    > >> > I didn't come from classic ASP so I can't speak for someone's been
    > >> > used to having "inline" code. So I personally like the separation
    > >> > that code-behind provides. And I'm not using v2 of the VS and if it

    >
    > >> > provides better editing/debugging capabilities, then that's great.
    > >> > This is one reason I haven't done my hard-core coding on the page
    > >> > itself because it has Intellisense, better debugging, etc.
    > >> >
    > >> > As for Mr. Rivers' complaint about ASP.NET in general as compared
    > >> > to ASP, he seems to be one who's more impressed by how fast (see
    > >> > his "VS.NET is 10 times slower than VB6" rant) or how pretty his
    > >> > code is, rather than the technology advantages ASP.NET and the .NET

    >
    > >> > framework provide. A rather sophomoric complaint if you ask me. He
    > >> > should roll up his sleaves and look at the technology. I would hope

    >
    > >> > he'd never go back to the primitive world of VB6/ASP if he
    > >> > understood the Framework better.
    > >> >
    > >> > Bottom line, if you like coding on your page, great. If you like
    > >> > code-behind, great.
    > >> > Remember, however, if you're on a development team, pick one or the

    >
    > >> > other.
    > >> > Settle it with a toss of a coin or arm-wrestle. Then stick to it.
    > >> > I've been involved in projects where there's been a mixture and it
    > >> > can be confusing going from one to the other and from an
    > >> > architecture standpoint, it's not good practice.
    > >> >
    > >> > -- John Harcourt
    > >> >
    > >> > "tom pester" wrote:
    > >> >
    > >> >> Hi Marina,
    > >> >>
    > >> >> > I find the 2 arguments you listed more then enough to support
    > >> >> > the reasons for doing it. Except with the change, that it more
    > >> >> > the promotes thinking about these 2 things as separate. There
    > >> >> > is a lot to be said from separating your UI from the business
    > >> >> > logic.
    > >> >>
    > >> >> I am all for the seperation of logic and presentation and business

    >
    > >> >> logic should defenetily go into its own space regardless of how
    > >> >> small the project is.
    > >> >> But the little code you write for wiring things up, ie that are
    > >> >> specific to the GUI, don't need seperation cause its specific and
    > >> >> thus not reasuable.
    > >> >>
    > >> >> A function that gets all orders from a database should be in a
    > >> >> class library (and I mean not code behind).
    > >> >> IMO A function that wires up the result to a datagrid doesn't have

    >
    > >> >> to be in a class.
    > >> >>
    > >> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    > >> >> transformed by a parser to a plain class :
    > >> >>
    > >> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    > >> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    > >> >>
    > >> >> So by that rational I do everything in a class file so I must be
    > >> >> doing it right ;)
    > >> >>
    > >> >> > And sorry, but your reasons for not doing just don't make sense
    > >> >> > to me.
    > >> >> > I don't care if I have 100 files or 50 files. You still just
    > >> >> > see one icon in VS, and you can either go to design view, or you

    >
    > >> >> > can go to code. You don't see twice as many files - so who
    > >> >> > cares if in reality there are?
    > >> >>
    > >> >> I hear you but I like to keep everything KISS. So there must be a
    > >> >> _good_ reason if I have to double the project in files.
    > >> >>
    > >> >> > In any case, microsoft didn't limit anyone to any one model of
    > >> >> > how things should be done. If this way works for you, go ahead.
    > >> >>
    > >> >> The arguments you make are all solid but for me the separation
    > >> >> between markup and wire up code (not Business Logic) is a logical
    > >> >> one.
    > >> >> You can make it a physical separition by splitting the file in 2.
    > >> >> But what does it give you? IMO not more power, except for the 2
    > >> >> reasons that are only a consequence of making it physical.
    > >> >>
    > >> >> Cheers,
    > >> >> Tom Pester
    > >> >>
    > >> >>
    > >> >>
    > >>
    > >>
    > >>
     
    John Rivers, Aug 29, 2005
    #19
  20. > If I understand it right, there is a compilation difference between
    > inline and codebehind. I do know that you can change inline code
    > without having to redploy the binary in the bin folder. That might look
    > good from one view, but seems to come at a performance cost.


    There is not much of a difference. The Page class is compiled the first time
    the Page is requested, and the compiled version is cached. It will expire
    from the cache eventually, but most of the time, the cached version is used.
    It is important to remember that the Page class itself is compiled from BOTH
    the Page Template and the CodeBehind class, in either case. That is why the
    Page INHERITS the CodeBehind when using a separate CodeBehind coding model.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    Paranoia is just a state of mind.

    "John Horst" <> wrote in message
    news:...
    > If I understand it right, there is a compilation difference between
    > inline and codebehind. I do know that you can change inline code
    > without having to redploy the binary in the bin folder. That might look
    > good from one view, but seems to come at a performance cost.
    >
    > As for all the books out there, most have been written on a marketing
    > assumption that the reader may not have VS (thus they use inline samples
    > and do not show the user how to make the most of the VS IDE). I think
    > that assumption is probably largely wrong.
    >
    > John
    >
    > -----Original Message-----
    > From: Kevin Spencer [mailto:]
    > Posted At: Monday, August 29, 2005 8:55 AM
    > Posted To: microsoft.public.dotnet.framework.aspnet
    > Conversation: TRICK: methods in ASPX pages with <%%> code blocks
    > Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks
    >
    >
    > Hi John,
    >
    > As far as CodeBehind is concerned, I am not aware of any significant
    > differences in the use of it versus not using it. The CodeBehind class
    > logic can be in the same file as the Template code and still be
    > separated from it (all at the top, for example). I feel that the most
    > important "Best Practices" consideration regarding Pages is that Pages
    > should not contain any business logic, only interface logic.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > Paranoia is just a state of mind.
    >
    > "John Harcourt" <> wrote in
    > message news:...
    >> No argument from me there.
    >> With the subject of code-behind, however, Best Practices indicate that

    >
    >> the size and scope of a project that you're dealing (and the
    >> developers) with can help determine if you should use code-behind or
    >> not. MS didn't stop the ability from writing in-line code. Many of
    >> the early .NET books (even from
    >> MSPress) hardly mentioned code-behind at all. MS's own Matrix tool
    >> doesn't support code-behind. So I can hardly be surprised to see
    >> hoards of professional developers following Best Practices as they
    >> know it, but not using code-behind. Totally legitimate.
    >> From a personal level I've always used code-behind, even for small

    > pages.
    >> I
    >> just like the separation it provides. But I have a good buddy who
    >> wrote ASP classic for years and finds code-behind a bit getting used
    >> to. His first instinct is to write in-line code.
    >>
    >> cheers.
    >>
    >> "Kevin Spencer" wrote:
    >>
    >>> > Bottom line, if you like coding on your page, great. If you like
    >>> > code-behind, great.
    >>> > Remember, however, if you're on a development team, pick one or the

    >
    >>> > other.
    >>> > Settle it with a toss of a coin or arm-wrestle. Then stick to it.
    >>> > I've been involved in projects where there's been a mixture and it
    >>> > can be confusing going from one to the other and from an
    >>> > architecture standpoint, it's not good practice.
    >>>
    >>> The real bottom line is, if you are serious about making a living as
    >>> a developer, adopt best practices. They are called "best practices"
    >>> because they improve the performance of the developer, and the
    >>> performance, scalability, and maintainability of the software that
    >>> the developer creates.
    >>> Best practices are arrived at by experienced developers who have
    >>> observed the problems and pitfalls of various methodologies, both by
    >>> their own experiences, and by observing the experiences of others,
    >>> over a long period of time.
    >>>
    >>> I was once told that "wisdom comes by experience, and experience by
    >>> lack of wisdom." However, the older I get, I realize that there is
    >>> another better way to come by wisdom, and that is by listening to
    >>> those who already have it.
    >>>
    >>> --
    >>> HTH,
    >>>
    >>> Kevin Spencer
    >>> Microsoft MVP
    >>> ..Net Developer
    >>> Paranoia is just a state of mind.
    >>>
    >>> "John Harcourt" <> wrote in
    >>> message news:...
    >>> >I don't have solid "evidence" of coding one way or the other. In
    >>> >most instances, it's simply user preference. The framework handles
    >>> >both the same way (ok there are a few differences, but not
    >>> >really). You can precompile your pages and you can compile the
    >>> >code-behind.
    >>> >
    >>> > I didn't come from classic ASP so I can't speak for someone's been
    >>> > used to having "inline" code. So I personally like the separation
    >>> > that code-behind provides. And I'm not using v2 of the VS and if it

    >
    >>> > provides better editing/debugging capabilities, then that's great.
    >>> > This is one reason I haven't done my hard-core coding on the page
    >>> > itself because it has Intellisense, better debugging, etc.
    >>> >
    >>> > As for Mr. Rivers' complaint about ASP.NET in general as compared
    >>> > to ASP, he seems to be one who's more impressed by how fast (see
    >>> > his "VS.NET is 10 times slower than VB6" rant) or how pretty his
    >>> > code is, rather than the technology advantages ASP.NET and the .NET

    >
    >>> > framework provide. A rather sophomoric complaint if you ask me. He
    >>> > should roll up his sleaves and look at the technology. I would hope

    >
    >>> > he'd never go back to the primitive world of VB6/ASP if he
    >>> > understood the Framework better.
    >>> >
    >>> > Bottom line, if you like coding on your page, great. If you like
    >>> > code-behind, great.
    >>> > Remember, however, if you're on a development team, pick one or the

    >
    >>> > other.
    >>> > Settle it with a toss of a coin or arm-wrestle. Then stick to it.
    >>> > I've been involved in projects where there's been a mixture and it
    >>> > can be confusing going from one to the other and from an
    >>> > architecture standpoint, it's not good practice.
    >>> >
    >>> > -- John Harcourt
    >>> >
    >>> > "tom pester" wrote:
    >>> >
    >>> >> Hi Marina,
    >>> >>
    >>> >> > I find the 2 arguments you listed more then enough to support
    >>> >> > the reasons for doing it. Except with the change, that it more
    >>> >> > the promotes thinking about these 2 things as separate. There
    >>> >> > is a lot to be said from separating your UI from the business
    >>> >> > logic.
    >>> >>
    >>> >> I am all for the seperation of logic and presentation and business

    >
    >>> >> logic should defenetily go into its own space regardless of how
    >>> >> small the project is.
    >>> >> But the little code you write for wiring things up, ie that are
    >>> >> specific to the GUI, don't need seperation cause its specific and
    >>> >> thus not reasuable.
    >>> >>
    >>> >> A function that gets all orders from a database should be in a
    >>> >> class library (and I mean not code behind).
    >>> >> IMO A function that wires up the result to a datagrid doesn't have

    >
    >>> >> to be in a class.
    >>> >>
    >>> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
    >>> >> transformed by a parser to a plain class :
    >>> >>
    >>> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
    >>> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
    >>> >>
    >>> >> So by that rational I do everything in a class file so I must be
    >>> >> doing it right ;)
    >>> >>
    >>> >> > And sorry, but your reasons for not doing just don't make sense
    >>> >> > to me.
    >>> >> > I don't care if I have 100 files or 50 files. You still just
    >>> >> > see one icon in VS, and you can either go to design view, or you

    >
    >>> >> > can go to code. You don't see twice as many files - so who
    >>> >> > cares if in reality there are?
    >>> >>
    >>> >> I hear you but I like to keep everything KISS. So there must be a
    >>> >> _good_ reason if I have to double the project in files.
    >>> >>
    >>> >> > In any case, microsoft didn't limit anyone to any one model of
    >>> >> > how things should be done. If this way works for you, go ahead.
    >>> >>
    >>> >> The arguments you make are all solid but for me the separation
    >>> >> between markup and wire up code (not Business Logic) is a logical
    >>> >> one.
    >>> >> You can make it a physical separition by splitting the file in 2.
    >>> >> But what does it give you? IMO not more power, except for the 2
    >>> >> reasons that are only a consequence of making it physical.
    >>> >>
    >>> >> Cheers,
    >>> >> Tom Pester
    >>> >>
    >>> >>
    >>> >>
    >>>
    >>>
    >>>

    >
    >
     
    Kevin Spencer, Aug 29, 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. Doug Holton
    Replies:
    20
    Views:
    829
    gabriele renzi
    Jun 26, 2004
  2. RadioSignal

    passing variables from .aspx.cs code pages to .aspx pages

    RadioSignal, Sep 12, 2005, in forum: ASP .Net Web Controls
    Replies:
    7
    Views:
    2,258
    Mirronelli
    Oct 22, 2005
  3. TEN TOD PSA

    TRICK: ASP.NET methods with code blocks

    TEN TOD PSA, Aug 18, 2005, in forum: ASP General
    Replies:
    1
    Views:
    126
    Bob Barrows [MVP]
    Aug 19, 2005
  4. matt
    Replies:
    1
    Views:
    278
    George Ogata
    Aug 6, 2004
  5. Steven Taylor
    Replies:
    9
    Views:
    260
    Brian Candler
    Apr 27, 2009
Loading...

Share This Page