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