468,553 Members | 1,458 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,553 developers. It's quick & easy.

WebForm objects in Business Tier?

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
Nov 19 '05 #1
8 1427
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" <ke***********************@hotmail.com> wrote in message
news:#O**************@tk2msftngp13.phx.gbl...
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

Nov 19 '05 #2
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" <ks******@takempis.com> wrote in message
news:eN**************@TK2MSFTNGP10.phx.gbl...
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" <ke***********************@hotmail.com> wrote in message
news:#O**************@tk2msftngp13.phx.gbl...
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


Nov 19 '05 #3
None of the objects mentioned render an interface.

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

"Keith-Earl" <ke***********************@hotmail.com> wrote in message
news:#m**************@TK2MSFTNGP11.phx.gbl...
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" <ks******@takempis.com> wrote in message
news:eN**************@TK2MSFTNGP10.phx.gbl...
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" <ke***********************@hotmail.com> wrote in message
news:#O**************@tk2msftngp13.phx.gbl...
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



Nov 19 '05 #4
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
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...
None of the objects mentioned render an interface.

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

"Keith-Earl" <ke***********************@hotmail.com> wrote in message
news:#m**************@TK2MSFTNGP11.phx.gbl...
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" <ks******@takempis.com> wrote in message
news:eN**************@TK2MSFTNGP10.phx.gbl...
> 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" <ke***********************@hotmail.com> wrote in message
> news:#O**************@tk2msftngp13.phx.gbl...
>> 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
>>
>>
>
>



Nov 19 '05 #5
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
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

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...
None of the objects mentioned render an interface.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
"Keith-Earl" <ke***********************@hotmail.com> wrote in message
news:#m**************@TK2MSFTNGP11.phx.gbl...
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" <ks******@takempis.com> wrote in message
news:eN**************@TK2MSFTNGP10.phx.gbl...

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" <ke***********************@hotmail.com> wrote in
message news:#O**************@tk2msftngp13.phx.gbl...

> 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

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

Keith

"john morales" <jmorales@NO_SPAM-gmail-R3M0VE_TH1S.com> wrote in message
news:68********************@msnews.microsoft.com.. .
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
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

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...
None of the objects mentioned render an interface.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
"Keith-Earl" <ke***********************@hotmail.com> wrote in message
news:#m**************@TK2MSFTNGP11.phx.gbl...

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" <ks******@takempis.com> wrote in message
news:eN**************@TK2MSFTNGP10.phx.gbl...

> 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" <ke***********************@hotmail.com> wrote in
> message news:#O**************@tk2msftngp13.phx.gbl...
>
>> 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


Nov 19 '05 #7
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" <ke***********************@hotmail.com> wrote in message
news:Op**************@TK2MSFTNGP14.phx.gbl...
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
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...
None of the objects mentioned render an interface.

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

"Keith-Earl" <ke***********************@hotmail.com> wrote in message
news:#m**************@TK2MSFTNGP11.phx.gbl...
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" <ks******@takempis.com> wrote in message
news:eN**************@TK2MSFTNGP10.phx.gbl...
> 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" <ke***********************@hotmail.com> wrote in message
> news:#O**************@tk2msftngp13.phx.gbl...
>> 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
>>
>>
>
>



Nov 19 '05 #8
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

"Kevin Spencer" <ks******@takempis.com> wrote in message
news:Ot**************@TK2MSFTNGP15.phx.gbl...
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" <ke***********************@hotmail.com> wrote in message
news:Op**************@TK2MSFTNGP14.phx.gbl...
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
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...
> None of the objects mentioned render an interface.
>
> --
> HTH,
> Kevin Spencer
> .Net Developer
> Microsoft MVP
> Neither a follower
> nor a lender be.
>
> "Keith-Earl" <ke***********************@hotmail.com> wrote in message
> news:#m**************@TK2MSFTNGP11.phx.gbl...
>> 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" <ks******@takempis.com> wrote in message
>> news:eN**************@TK2MSFTNGP10.phx.gbl...
>> > 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" <ke***********************@hotmail.com> wrote in
>> > message
>> > news:#O**************@tk2msftngp13.phx.gbl...
>> >> 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
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 19 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Brian Kiser | last post: by
38 posts views Thread by Radi Radichev | last post: by
5 posts views Thread by G. Stewart | last post: by
12 posts views Thread by BillE | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by UniDue | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.