WebForm objects in Business Tier?

Discussion in 'ASP .Net' started by Keith-Earl, Dec 7, 2004.

  1. Keith-Earl

    Keith-Earl Guest

    Okay, looking for a Best Practice. We are building a classic three tier app
    in VB.NET. When we load up a WebForm we have access to very useful objects
    such as the Session object. We frequently store short lists in Session or
    even Application objects and retrieve them later without having to make a
    round trip to the db.

    We think the best place to do all this is in the Business tier and not to
    clutter up the client (WebForm). In order to access the Session and
    Application objects we need to add references to these objects. Is this a
    good idea?

    We just want to push some of the busy work down a tier even though we need
    objects that are accessible at the client tier.

    What is the best way to implement this design?

    Many thanks,
    Keith
     
    Keith-Earl, Dec 7, 2004
    #1
    1. Advertisements

  2. The System.Web.HttpContext.Current property is a static property that
    returns the current HttpContext. You can access all the intrinsic Context
    objects from it:

    System.Web.HttpContext.Current.Session
    System.Web.HttpContext.Current.Cache
    System.Web.HttpContext.Current..Application
    System.Web.HttpContext.Current..Server

    etc.

    --
    HTH,
    Kevin Spencer
    ..Net Developer
    Microsoft MVP
    Neither a follower
    nor a lender be.
     
    Kevin Spencer, Dec 7, 2004
    #2
    1. Advertisements

  3. Keith-Earl

    Keith-Earl Guest

    Thanks, Kevin, but is this a good approach?
    We definitley want to get the "busyness" of this code out of the client
    tier, but will it make our business tier too hefty?

    Thanks for the reply!
    Keith
     
    Keith-Earl, Dec 7, 2004
    #3
  4. None of the objects mentioned render an interface.

    --
    HTH,
    Kevin Spencer
    ..Net Developer
    Microsoft MVP
    Neither a follower
    nor a lender be.
     
    Kevin Spencer, Dec 7, 2004
    #4
  5. Keith-Earl

    Keith-Earl Guest

    Okay, I am a little slow, I'll admit it...when you say "None of the objects
    mentioned render an interface." does that mean it would not be a big deal to
    put this code here? Just did not want to bloat our business tier object if
    this was a bad practice (refer to obvious web objects down in the business
    tier.

    Remember back in Classic ASP when you could store a connection object in a
    session variable? It would work, but would not scale. MS told us not to do
    it. Same question for this practice. I know it will work, but will we pay
    a big price when it comes time to scale?

    Thanks, you have been a great help.

    Keith
     
    Keith-Earl, Dec 7, 2004
    #5
  6. Keith-Earl

    john morales Guest

    Hello Keith-Earl,

    Technically you can add the references to the Business Components and your
    application would work great. But the question is really up to you and your
    team to decide. I personally prefer the "application logic" tier to not have
    any knowledge of web request context objects. As it makes it easier to create
    unit tests to test these methods and objects. But depending on the application/requirements
    for reuse/maintainabilty,etc this obfuscation overhead might not be necessary.


    If you look at the quickstarts that microsoft publishes the middletier objects
    usually have references to the webcontext and use them intrinsically. On
    the otherhand you can find articles on the net "guiding" you that this is
    a bad practice. At the end either way is good, depending on the specs. its
    all relative.

    -john
     
    john morales, Dec 7, 2004
    #6
  7. Keith-Earl

    Keith-Earl Guest

    Thank you, sir. There is just so much out there to consider. One person's
    elegant solution is another's hack.

    Keith
     
    Keith-Earl, Dec 7, 2004
    #7
  8. It's all a matter of your architecture. First, if you are developing
    re-usable Business classes, and you expect that they may be used in a
    non-ASP.Net app, putting references to ASP.Net objects would be a mistake.
    However, if you don't plan on using them in a non-ASP.Net app, it's fine.
    IOW, there should be nothing in your business classes that either contains
    UI code, or would break them if you ported them to some app that the
    inclusion of ASP.Net objects would break.

    --
    HTH,
    Kevin Spencer
    ..Net Developer
    Microsoft MVP
    Neither a follower
    nor a lender be.
     
    Kevin Spencer, Dec 7, 2004
    #8
  9. Keith-Earl

    Keith-Earl Guest

    It makes perfect sense now. At this time we have no intentions of making
    the Business tier client-neutral, but we will share this code among many
    ASP.net web apps.

    We will push the code to the Business tier in order to make subsequent *web*
    apps easiser to implement. Thanks for a great discussion.

    Keith
     
    Keith-Earl, Dec 7, 2004
    #9
    1. Advertisements

Ask a Question

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

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