n tier development strategy question

I don't know where to post this question-or maybe its a comment and I am
just looking for reactions.
We are developing a multi-tiered web app where all database access goes
through a Business Object layer which resides on a machine that is not the
db server.
I am trying to develop the Business Objects in such a way that the web tier
which uses them does not access datasets directly themselves. Instead, the
Business Objects layers provides objects and collection classes representing
the data in the database.
It seems that I am always presented with a trade off of choosing between
encapsulation and performance.
For example, in order to instantiate an object A, the object needs to talk
to the database. So the code for this is encaptulated in A.New. But then, if
object B needs three local instances of object A, each instance will result
in A.New making 3 round trips to the database! To code for performance, I
would have have B return ALL of the data needed to instantiate 3 A's and
pass that to a Friend A.New constructor, but this is at the expenses of
encapsulation and reusuability of objects!
Does this make sense!
HHHHHHHHHHHHHHEEEEEEEEEEEEEEEEEEEEEEEEEE
EEELLLLLLLLLLLLLLLLLLLP
It's driving me nuts not knowing what to do!
Is this a common design problem faced by apps that have a Biz Object layer?The business logic itself may be unique to your applicaiton, but there are
proven and widely accepted design patterns for passing data between the
tiers. For example:
Data Access Application Block
http://msdn.microsoft.com/library/d...aab.
asp
Designing Data Tier Components and Passing Data Through Tiers
http://msdn.microsoft.com/library/d...Gag
.asp
"Chad" <chad.dokmanovich@.unisys.com> wrote in message
news:djj90u$qo0$1@.trsvr.tr.unisys.com...
>I don't know where to post this question-or maybe its a comment and I am
>just looking for reactions.
> We are developing a multi-tiered web app where all database access goes
> through a Business Object layer which resides on a machine that is not the
> db server.
> I am trying to develop the Business Objects in such a way that the web
> tier which uses them does not access datasets directly themselves.
> Instead, the Business Objects layers provides objects and collection
> classes representing the data in the database.
> It seems that I am always presented with a trade off of choosing between
> encapsulation and performance.
> For example, in order to instantiate an object A, the object needs to talk
> to the database. So the code for this is encaptulated in A.New. But then,
> if object B needs three local instances of object A, each instance will
> result in A.New making 3 round trips to the database! To code for
> performance, I would have have B return ALL of the data needed to
> instantiate 3 A's and pass that to a Friend A.New constructor, but this is
> at the expenses of encapsulation and reusuability of objects!
>
> Does this make sense!
>
> HHHHHHHHHHHHHHEEEEEEEEEEEEEEEEEEEEEEEEEE
EEELLLLLLLLLLLLLLLLLLLP
> It's driving me nuts not knowing what to do!
> Is this a common design problem faced by apps that have a Biz Object
> layer?
>
>|||On Mon, 24 Oct 2005 14:27:22 -0400, "Chad"
<chad.dokmanovich@.unisys.com> wrote:
>Is this a common design problem faced by apps that have a Biz Object layer?
Yes.
Google is your friend, it's been endlessly discussed.
My position is that a better appreciation of relational databases as
hold a data model, rather than loose tables, is the first step towards
wisdom.
J.