OOP data storage vs. SQL calls

[Victor Fees]

I have a general question for which I would like to get some general input
from the online community.

I'm building an asp.net web application that will make extensive use of a
SQL Server 2K database. One of the relationships in this database is many
Tasks to a 1 Project. I can see two basic ways to manage this in my web
application: The first is by creating a Project class and a Task class,
and talking directly to the database with either -- meaning that on each
page where I need data about either a Project or a Task, I make the stored
procedure calls and add, modify, or delete the data appropriately.

The other is to use the IEnumerable interface so that I can do clever
things like Project.Tasks.Add() and Project.Tasks.Modify(), etc. But, in
this model, it seems to make more sense to get all the necessary data upon
instantiation of the Project class, and then carry it around in a Session
object, and make database calls as I need to in order to keep the class and
the database in sync.

OK, so here's the question -- which is more efficient, and is there a point
of diminishing returns for the preferred answer. In short, does it make
more sense to have more database calls (potentially every page), or to have
one big one, and carry the enumerated object around in Session, making
calls only as necessary.

Please note that I realize that number of concurrent users, number of
layers in the architecture, etc. are all factors in making the decision . .
.. I'm looking for an "all other things being equal, x is more efficient,
and here's why . . . "

Anyone got an opinion on this? Any input is appreciated.

Thanks,
Vic Fees

[dd]

The rule of thuimb is:

1. WEB application (N-tiered) -> use DB for caching.
2. Client/Server -> user memory for caching.

This an old problem that any design faces at the very beginning, i.e. where
to cache data.
If you want your WEB application to be scalable and perform well you will be
better off using DB for caching, although it does not exclude caching of
small amount of data in Session object or ViewState.
DB calls are not a problem nowadays at all, networks are fast. BTW, I have
seen projects where people were trying to implement Client/Server approach
to WEB enabled applications, and they usually failed miserably.

"Victor Fees" <vf************@seventhfloorinc.com> wrote in message
news:Xn**********************************@207.46.2 48.16...

I have a general question for which I would like to get some general input
from the online community.

I'm building an asp.net web application that will make extensive use of a
SQL Server 2K database. One of the relationships in this database is many
Tasks to a 1 Project. I can see two basic ways to manage this in my web
application: The first is by creating a Project class and a Task class,
and talking directly to the database with either -- meaning that on each
page where I need data about either a Project or a Task, I make the stored
procedure calls and add, modify, or delete the data appropriately.

The other is to use the IEnumerable interface so that I can do clever
things like Project.Tasks.Add() and Project.Tasks.Modify(), etc. But, in
this model, it seems to make more sense to get all the necessary data upon
instantiation of the Project class, and then carry it around in a Session
object, and make database calls as I need to in order to keep the class and the database in sync.

OK, so here's the question -- which is more efficient, and is there a point of diminishing returns for the preferred answer. In short, does it make
more sense to have more database calls (potentially every page), or to have one big one, and carry the enumerated object around in Session, making
calls only as necessary.

Please note that I realize that number of concurrent users, number of
layers in the architecture, etc. are all factors in making the decision . .. . I'm looking for an "all other things being equal, x is more efficient,
and here's why . . . "

Anyone got an opinion on this? Any input is appreciated.

Thanks,
Vic Fees

[dd]

Actually, I can give you an example that kills your solution #2 (keeping
state in Session object).
Let's imagine that you have implemented this solution. I am a user who is
working with data and entering some new data. Then in the middle of my work
my phone rings, and I spend 25 min talking to somebody on the phone. When I
get back to the application, all my data is gone, since my session has
expired. I did not even have a chance to save it.
You can increase Session timeout, but where is the limit? And by increasing
session timeout you will load your WEB server with lots of data that you may
not need. This solution is not scalable.

"dd" <aa*@aaa.com> wrote in message
news:Og********************@news20.bellglobal.com. ..

The rule of thuimb is:

1. WEB application (N-tiered) -> use DB for caching.
2. Client/Server -> user memory for caching.

This an old problem that any design faces at the very beginning, i.e. where to cache data.
If you want your WEB application to be scalable and perform well you will be better off using DB for caching, although it does not exclude caching of
small amount of data in Session object or ViewState.
DB calls are not a problem nowadays at all, networks are fast. BTW, I have
seen projects where people were trying to implement Client/Server approach
to WEB enabled applications, and they usually failed miserably.

"Victor Fees" <vf************@seventhfloorinc.com> wrote in message
news:Xn**********************************@207.46.2 48.16...

I have a general question for which I would like to get some general input from the online community.

I'm building an asp.net web application that will make extensive use of a SQL Server 2K database. One of the relationships in this database is many Tasks to a 1 Project. I can see two basic ways to manage this in my web
application: The first is by creating a Project class and a Task class,
and talking directly to the database with either -- meaning that on each
page where I need data about either a Project or a Task, I make the stored procedure calls and add, modify, or delete the data appropriately.

The other is to use the IEnumerable interface so that I can do clever
things like Project.Tasks.Add() and Project.Tasks.Modify(), etc. But, in this model, it seems to make more sense to get all the necessary data upon instantiation of the Project class, and then carry it around in a Session object, and make database calls as I need to in order to keep the class and

the database in sync.

OK, so here's the question -- which is more efficient, and is there a

point

of diminishing returns for the preferred answer. In short, does it make
more sense to have more database calls (potentially every page), or to

have

one big one, and carry the enumerated object around in Session, making
calls only as necessary.

Please note that I realize that number of concurrent users, number of
layers in the architecture, etc. are all factors in making the decision

.. .

. I'm looking for an "all other things being equal, x is more efficient,
and here's why . . . "

Anyone got an opinion on this? Any input is appreciated.

Thanks,
Vic Fees