WebForm objects in Business Tier?

[Keith-Earl]

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

 

[Kevin Spencer]

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.

 

[Keith-Earl]

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

 

[Kevin Spencer]

None of the objects mentioned render an interface.

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

 

[Keith-Earl]

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

 

[john morales]

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

 

[Keith-Earl]

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

Keith

 

[Kevin Spencer]

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.

 

[Keith-Earl]

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