Persisting business layer objects

[headware]

I am new to 3-tiered design and am in the process of designing an
application that will work with ASP.NET as well as Windows Forms (and
possibly with a PDA of some sort down the road). My question is about
the statefulness of business objects. In some of the examples that
I've seen of 3-tiered systems using ASP.NET, the business objects are
recreated every time they are accessed. They are not kept in the
Session variable for use next time the GUI needs them. This seems like
it could come with considerable performance penalties, but would be
simpler to maintain. What are the arguments for and against trying to
maintain the business layer objects between postbacks? Do non web
based applications (like Win Forms) usually keep the business objects
in memory when not in use?

Thanks,
Dave

[Kevin Spencer]

Hi Dave,

Let's start with your last question:

Do non web
based applications (like Win Forms) usually keep the business objects
in memory when not in use?
A desktop application has a constant and unchanging memory space to work
with. So, obviously, the answer is "yes."

A web application is made up of many separate pages that are served up via
HTTP to client browsers. HTTP is a stateless protocol, which means that each
Request and Response happens "in a vacuum" (so to speak). The server forgets
about the last Request as soon as it has fulfilled it. There is no
persistence of memory, other than the "containers" that ASP.Net maintains,
including Application, Session, etc. These exist for that reason
(statelessness).

Now, as to your first question:
What are the arguments for and against trying to
maintain the business layer objects between postbacks?
There is no "one size fits all" rule for this. It depends upon your
requirements, and how, when, and where these objects are being used. If, for
example, you have a class which provides the data for menus that are used in
all pages, you would most likely store that data in the Application Cache.
If, however, a business class is only used on a single page, it might be
best to instantiate it with each new Request for that page. On the other
hand, if the class is used on many pages by a single user, it might be best
to cache it in Session State.

The bottom line is, it's a trade-off. Caching objects costs you RAM on the
server. Not caching them costs you processing. You need to determine, based
upon the individual usage of these classes, whether the trade-off will be
less expensive overall.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"headware" <he******@aol.com> wrote in message
news:e3**************************@posting.google.c om... I am new to 3-tiered design and am in the process of designing an
application that will work with ASP.NET as well as Windows Forms (and
possibly with a PDA of some sort down the road). My question is about
the statefulness of business objects. In some of the examples that
I've seen of 3-tiered systems using ASP.NET, the business objects are
recreated every time they are accessed. They are not kept in the
Session variable for use next time the GUI needs them. This seems like
it could come with considerable performance penalties, but would be
simpler to maintain. What are the arguments for and against trying to
maintain the business layer objects between postbacks? Do non web
based applications (like Win Forms) usually keep the business objects
in memory when not in use?

Thanks,
Dave

[headware]

Kevin,

I appreciate the reply. I guess we'll have to be careful to make the
business layer objects work independently of whether they are being
stored in memory (as they would be in Win Forms) or whether they are
created every time they are accessed (as they might be in Web Forms).

Thanks,
Dave

"Kevin Spencer" <ks******@takempis.com> wrote in message news:<u0**************@TK2MSFTNGP11.phx.gbl>...

Hi Dave,

Let's start with your last question:

Do non web
based applications (like Win Forms) usually keep the business objects
in memory when not in use?

A desktop application has a constant and unchanging memory space to work
with. So, obviously, the answer is "yes."

A web application is made up of many separate pages that are served up via
HTTP to client browsers. HTTP is a stateless protocol, which means that each
Request and Response happens "in a vacuum" (so to speak). The server forgets
about the last Request as soon as it has fulfilled it. There is no
persistence of memory, other than the "containers" that ASP.Net maintains,
including Application, Session, etc. These exist for that reason
(statelessness).

Now, as to your first question:

What are the arguments for and against trying to
maintain the business layer objects between postbacks?

There is no "one size fits all" rule for this. It depends upon your
requirements, and how, when, and where these objects are being used. If, for
example, you have a class which provides the data for menus that are used in
all pages, you would most likely store that data in the Application Cache.
If, however, a business class is only used on a single page, it might be
best to instantiate it with each new Request for that page. On the other
hand, if the class is used on many pages by a single user, it might be best
to cache it in Session State.

The bottom line is, it's a trade-off. Caching objects costs you RAM on the
server. Not caching them costs you processing. You need to determine, based
upon the individual usage of these classes, whether the trade-off will be
less expensive overall.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"headware" <he******@aol.com> wrote in message
news:e3**************************@posting.google.c om...

I am new to 3-tiered design and am in the process of designing an
application that will work with ASP.NET as well as Windows Forms (and
possibly with a PDA of some sort down the road). My question is about
the statefulness of business objects. In some of the examples that
I've seen of 3-tiered systems using ASP.NET, the business objects are
recreated every time they are accessed. They are not kept in the
Session variable for use next time the GUI needs them. This seems like
it could come with considerable performance penalties, but would be
simpler to maintain. What are the arguments for and against trying to
maintain the business layer objects between postbacks? Do non web
based applications (like Win Forms) usually keep the business objects
in memory when not in use?

Thanks,
Dave