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

Discussion in 'ASP .Net' started by Kevin Spencer, Aug 6, 2003.

  1. Hi Nuno,

    After analyzing 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
    http://www.takempis.com
    Complex things are made up of
    lots of simple things.

    "Nuno Borges" <> wrote in message
    news:0dc601c35c3b$2056a140$...
    > 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, documentation, 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 document to capture all session variables.
    > One person is responsible for maintaining this document.
    > 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 documentation 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, Aug 6, 2003
    #1
    1. Advertising

  2. Kevin Spencer

    David Browne Guest

    "Kevin Spencer" <> wrote in message
    news:Od%...
    > Hi Nuno,
    >
    > After analyzing 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, Aug 6, 2003
    #2
    1. Advertising

  3. "Kevin Spencer" <> wrote in message
    news:...
    > > 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
     
    John Saunders, Aug 6, 2003
    #3
    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. David Bowey
    Replies:
    1
    Views:
    450
    Steve C. Orr [MVP, MCSD]
    Mar 16, 2005
  2. =?Utf-8?B?SCBQb3dlbGw=?=

    ASP.NET Design and Development Best Practices?

    =?Utf-8?B?SCBQb3dlbGw=?=, Aug 9, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    1,714
    Kevin Spencer
    Aug 10, 2007
  3. David Bowey

    Best Practices: Porting ASCX control to compiled Custom Control?

    David Bowey, Mar 16, 2005, in forum: ASP .Net Building Controls
    Replies:
    1
    Views:
    178
    Steve C. Orr [MVP, MCSD]
    Mar 16, 2005
  4. David Bowey
    Replies:
    1
    Views:
    147
    Steve C. Orr [MVP, MCSD]
    Mar 16, 2005
  5. Chicken McNuggets

    Best book on C gotchas and best practices?

    Chicken McNuggets, Jul 31, 2013, in forum: C Programming
    Replies:
    9
    Views:
    275
    Fred J. Tydeman
    Aug 5, 2013
Loading...

Share This Page