Professional Web Applications Themes

Development best practices and knowing when to exercise control over development - ASP.NET General

Hi Nuno, After yzing your message, I found that most of it was purely theoretical. The actual issue you discussed was regarding how to control use of Session by developers in a team. That's a good thing to do, of course! So, rather than deal with all of the other issues you discussed, how about we deal with just that one? As use of Session is something which should be limited as much as possible, I would require any use of Session in code to be approved before it could be implemented. -- HTH, Kevin Spencer Microsoft MVP ..Net Developer ...

  1. #1

    Default Re: Development best practices and knowing when to exercise control over development

    Hi Nuno,

    After yzing your message, I found that most of it was purely
    theoretical. The actual issue you discussed was regarding how to control use
    of Session by developers in a team. That's a good thing to do, of course!
    So, rather than deal with all of the other issues you discussed, how about
    we deal with just that one? As use of Session is something which should be
    limited as much as possible, I would require any use of Session in code to
    be approved before it could be implemented.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    [url]http://www.takempis.com[/url]
    Complex things are made up of
    lots of simple things.

    "Nuno Borges" <nuno.borgestequilasoftware.com> wrote in message
    news:0dc601c35c3b$2056a140$a601280aphx.gbl...
    > This post is directed to all application architects and
    > team leads.
    >
    > My company is currently retooling itself for web
    > application development, and as most of you have
    > experienced with this type of transition, a lot of work
    > must be done up front to design/build/test your
    > architecture, create a programming model for your
    > developers, create and execute a strict adherence to
    > methodology, doentation, processes, etc. All of you
    > know the drill.
    >
    > The struggle i am having with my team is trying to
    > determine where the fine line is between exercising
    > extreme control over development and allowing them to
    > define the process. The trade-off here is obvious; more
    > control = more design and more development but more easily
    > maintained code VS less control = Fast development and
    > design and less maintainable code. A happy medium is what
    > we continually strive for to achieve best results,
    > however, i have one particular example that i can use to
    > illstrate my issue more clearly.
    >
    > The current project is designed for an intranet corporate
    > accounting information system.
    >
    > We are toying with the idea of managing how a development
    > team (now 6 but will be more than 10 soon) uses the
    > session object. We all know that memory usage on a Web
    > Server is a sensitive topic, and that allowing developers
    > to use the Session object carelessly can lead to disaster.
    > Blind trust works well in a small team, but when you have
    > a larger team that is often disconnected geographically or
    > culturally, you can't always rely on the best intentions
    > of developers. After all, it is not their responsibility
    > to manage Web Server resources; as this often squarely
    > lands on the shoulders of the lead architect or the
    > operational architect.
    >
    > So, how do you employ a measure of control that empowers
    > the architect to continually keep tabs on how the session
    > object is used? (million dollar question) Here are some
    > possible answers to which i would appreciate any replies.
    >
    > 1. Keep a word doent to capture all session variables.
    > One person is responsible for maintaining this doent.
    > This will later be used to derive a baseline for memory
    > usage during load testing.
    >
    > 2. Add all session variables to web.config or a different
    > XML file, to be loaded into application memory, which in
    > effect becomes a form of doentation as well. A wrapper
    > is used to manipulate all Session requests. This will
    > ensure that developers cannot use session variables unless
    > they have been included in the xml file. The wrapper is
    > also useful if i want to change the implementation of the
    > session state management (don't have to recompile all code
    > currently referencing the session object directly).
    >
    > 3. Trust the developers to use Session appropriately and
    > monitor this periodically with code reviews. Certainly the
    > fastest and easiest method, but i wouldn't want to find a
    > problem 2 days prior to a major deadline.
    >
    > Maybe you have more creative ideas of tackling this
    > specific problem or the general question as a whole.
    > Either way i would love to read your ideas on the matter.
    >
    > Thanks in advance,
    >
    > Nuno
    >
    >

    Kevin Spencer Guest

  2. #2

    Default Re: Development best practices and knowing when to exercise control over development

    "Nuno Borges" <nuno.borgestequilasoftware.com> wrote in message
    news:0dc601c35c3b$2056a140$a601280aphx.gbl...
    > 3. Trust the developers to use Session appropriately and
    > monitor this periodically with code reviews. Certainly the
    > fastest and easiest method, but i wouldn't want to find a
    > problem 2 days prior to a major deadline.
    >
    This would be my choice. Your code review and your testing should find any
    problems long before your major deadline.

    The kind of guidelines I'd place on session variables include that any
    objects placed in Session should be serializable, and that they should not
    cause performance problems. I would not depend on the object size as a
    guideline, as that may very well not imply a performance problem.

    I'd also impose naming guidelines and I'd require that any session variables
    which only make sense during a particular part of a session be destroyed at
    the end of that part. For instance, One might maintain some session
    variables while the user is filling out a multi-page form, but when the
    multi-page form is finally submitted successfully, I'd destroy any session
    state which was maintained specifically for that form.

    --
    John Saunders
    Internet Engineer
    [email]john.saunderssurfcontrol.com[/email]


    John Saunders Guest

  3. #3

    Default Re: Development best practices and knowing when to exercise control over development

    "Kevin Spencer" <kevintakempis.com> wrote in message
    news:Od%23NFbEXDHA.1640TK2MSFTNGP10.phx.gbl...
    > Hi Nuno,
    >
    > After yzing your message, I found that most of it was purely
    > theoretical. The actual issue you discussed was regarding how to control
    use
    > of Session by developers in a team. That's a good thing to do, of course!
    > So, rather than deal with all of the other issues you discussed, how about
    > we deal with just that one? As use of Session is something which should be
    > limited as much as possible,
    Only as [concurrent users] * [session size] begins to approach [web server
    ram]. Until then session state is practically free. For some kinds of
    application, this isn't a big problem.

    Since using session aggresively can radically simplify coding, and improve
    performance, especially for complex, data-rich pages which do many
    post-backs, the memory usage may be well worth it.

    David


    David Browne Guest

  4. #4

    Default Re: Development best practices and knowing when to exercise control over development

    "Kevin Spencer" <kevintakempis.com> wrote in message
    news:ub5dhAGXDHA.2640TK2MSFTNGP09.phx.gbl...
    > > Only as [concurrent users] * [session size] begins to approach [web
    server
    > > ram]. Until then session state is practically free. For some kinds of
    > > application, this isn't a big problem.
    >
    > A web application, like any other application, is not a static entity. It
    > evolves.
    But, Kevin, it won't necessarily evolve in a way which requires that session
    state size be restricted. Why make that assumption now, requiring that more
    development resources be spent today to find some other technique than
    session state, only to find out years later that session state size wouldn't
    have been a problem after all?

    Also, some of the reasons we used to have for avoiding Session state had to
    do with how COM worked, and had nothing to do with the size of the objects
    stored in session state. We should consider reevaluting our usage of session
    state and other things which have changed radically in .NET.
    --
    John Saunders
    Internet Engineer
    [email]john.saunderssurfcontrol.com[/email]


    John Saunders Guest

  5. #5

    Default Re: Development best practices and knowing when to exercise control over development

    Hi Kevin, thank you for your response.

    I agree that we need to find that sweet spot between
    exercising some control without incurring too much
    overhead or clerical work between the developers and the
    architects. Implementing control just for the sake of
    doing it doesn't make much sense, unless it relates to
    something that has a critical impact on the health of your
    application and the servers it resides on.

    Since our application will not experience unusually large
    amounts of concurrent usage, i don't think i need to worry
    about the Session object as much as i would for a high
    traffic e-commerce site for instance. I'm still debating
    wether i should wrap it because that would make it easier
    for me to change the implementation of session in the
    future (server farm / site server / database / etc).

    However, some measure of control is required, and your
    recommendation of tracing out non-approved session
    variables at the session_end stage is sound advice. I
    think we will attempt this approach.

    Thanks for your advice,

    Nuno
    >-----Original Message-----
    >
    >"Nuno Borges" <nuno.borgestequilasoftware.com> wrote in
    message
    >news:0dc601c35c3b$2056a140$a601280aphx.gbl...
    >> This post is directed to all application architects and
    >> team leads.
    >>
    >> My company is currently retooling itself for web
    >> application development, and as most of you have
    >> experienced with this type of transition, a lot of work
    >> must be done up front to design/build/test your
    >> architecture, create a programming model for your
    >> developers, create and execute a strict adherence to
    >> methodology, doentation, processes, etc. All of you
    >> know the drill.
    > . . .
    >
    >i would appreciate any replies.
    >>
    >> 1. Keep a word doent to capture all session
    variables.
    >> One person is responsible for maintaining this doent.
    >> This will later be used to derive a baseline for memory
    >> usage during load testing.
    >>
    >> 2. Add all session variables to web.config or a
    different
    >> XML file, to be loaded into application memory, which in
    >> effect becomes a form of doentation as well. A
    wrapper
    >> is used to manipulate all Session requests. This will
    >> ensure that developers cannot use session variables
    unless
    >> they have been included in the xml file. The wrapper is
    >> also useful if i want to change the implementation of
    the
    >> session state management (don't have to recompile all
    code
    >> currently referencing the session object directly).
    >
    >I would say this is the general way to go. But it might
    be a little too
    >restrictive to limit session variables to those on a
    list. Also it inserts
    >an administrative activity into the small cycles of page
    development.
    >Perhaps on session_end, just trace out all the session
    variables not on the
    >approved list, for use in code review.
    >
    >Using a custom subclass of System.Web.UI.Page as the base
    for all your
    >codebehind classes is a handy way to enforce coding
    practices in a way that
    >enhances developer productivity. My favorite way to
    enforce standards is to
    >make it very easy to do it the right way.
    >
    >David
    >
    >
    >.
    >
    Nuno Borges Guest

Similar Threads

  1. Exception handling in server control development
    By Sundararajan in forum ASP.NET Building Controls
    Replies: 0
    Last Post: September 10th, 06:33 AM
  2. Server control development
    By Sundararajan in forum ASP.NET Building Controls
    Replies: 2
    Last Post: April 8th, 05:03 PM
  3. Best practices for content development in shockwave and Director
    By RussellBan webforumsuser@macromedia.com in forum Macromedia Director Basics
    Replies: 0
    Last Post: December 12th, 04:16 PM
  4. Control development
    By The_Boss in forum ASP.NET Building Controls
    Replies: 2
    Last Post: September 5th, 12:48 AM
  5. what to use for development
    By Arthur Marsh in forum Sun Solaris
    Replies: 0
    Last Post: July 11th, 02:11 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139