n-tier performance trade-off (guidance needed)

[David]

I understand the need for n-tier architecture if an app is to be scaled-up
for server farm deployments. And I can also appreciate that separating UI
from business-logic from data-access is simply good design, if only from the
point-of-view of "encapsulation" and functional layering.

HOWEVER, I'm having a hard time justifying to our devl staff (many of who
are 20+ year veterans, like myself), why in a "desktop" app which will never
be deployed in a server-farm environment that we need to incur the overhead
of having separate physical layers (be they web services or remoting).

And more specifically, why develop in a "stateless" paradigm, in which on
every user interaction we instantiate the BL which instantiates the DAL? (as
Duwamish and other examples do).

Why not just have the "upper" layer instantiate the "lower" object ONCE and
then hold that instance reference? Again, I fully appreciate why a stateless
design is needed for server farms. But why incur the overhead of repeated
object instantiation/collection for a "desktop" app?

Or have we gotten to the point where the mere idea of a "logically layered
but physically monolithic" app is now heresy?

(BTW: is there a newsgroup that has a general but CONCRETE discussion of
n-tier practicality?)

Thanks,

David

[Jorge L Matos [MCSD.NET]]

I agree with you, creating objects for each method seems like an inefficent
thing to do. I can tell you that the runtime's garbage collector is designed
to efficiently remove objects from the heap that are short-lived so even if
you are creating an object on each method call, it should not adversly affect
performance. If you want to avoid the object creation code, then I suggest
you consider the Singleton design pattern so that once you create the object,
you hang onto it and avoid creating it again upon subsequent use.

--
Jorge L. Matos

"David" wrote:

I understand the need for n-tier architecture if an app is to be scaled-up
for server farm deployments. And I can also appreciate that separating UI
from business-logic from data-access is simply good design, if only from the
point-of-view of "encapsulation" and functional layering.

HOWEVER, I'm having a hard time justifying to our devl staff (many of who
are 20+ year veterans, like myself), why in a "desktop" app which will never
be deployed in a server-farm environment that we need to incur the overhead
of having separate physical layers (be they web services or remoting).

And more specifically, why develop in a "stateless" paradigm, in which on
every user interaction we instantiate the BL which instantiates the DAL? (as
Duwamish and other examples do).

Why not just have the "upper" layer instantiate the "lower" object ONCE and
then hold that instance reference? Again, I fully appreciate why a stateless
design is needed for server farms. But why incur the overhead of repeated
object instantiation/collection for a "desktop" app?

Or have we gotten to the point where the mere idea of a "logically layered
but physically monolithic" app is now heresy?

(BTW: is there a newsgroup that has a general but CONCRETE discussion of
n-tier practicality?)

Thanks,

David

[Patrice]

So don't.

I really don't see why you would have to physically partition an application
if there is no need for this(IMO you likely see that it's best to have at
least logical layers). For creating this is similar. Actually depending on
how your application is architectured it could be also really easy to switch
from one model to another...

Patrice

--

"David" <Da***@discussions.microsoft.com> a écrit dans le message de
news:73**********************************@microsof t.com...

I understand the need for n-tier architecture if an app is to be scaled-up
for server farm deployments. And I can also appreciate that separating UI
from business-logic from data-access is simply good design, if only from the point-of-view of "encapsulation" and functional layering.

HOWEVER, I'm having a hard time justifying to our devl staff (many of who
are 20+ year veterans, like myself), why in a "desktop" app which will never be deployed in a server-farm environment that we need to incur the overhead of having separate physical layers (be they web services or remoting).

And more specifically, why develop in a "stateless" paradigm, in which on
every user interaction we instantiate the BL which instantiates the DAL? (as Duwamish and other examples do).

Why not just have the "upper" layer instantiate the "lower" object ONCE and then hold that instance reference? Again, I fully appreciate why a stateless design is needed for server farms. But why incur the overhead of repeated
object instantiation/collection for a "desktop" app?

Or have we gotten to the point where the mere idea of a "logically layered
but physically monolithic" app is now heresy?

(BTW: is there a newsgroup that has a general but CONCRETE discussion of
n-tier practicality?)

Thanks,

David

[John Timney \(ASP.NET MVP\)]

There is no correct answer for you. We split apps up in tiers as we often
distribute the business and data functionality geographically to reduce
network bandwidth or because we want to re-use functionality without rework,
especially when we want differently branded sites pretty much doing most of
the same thing or aimed at different groups (internet/extranet for example).

Where you start seeing benefits in a desktop app is often related to using
objtects for common functionality across many apps, or choosing the
geographical split. Few benefits can probably be gained from developing a
single interface app for a single puropose when business functionality is
very self contained and will not ever need to be shared or reused- however,
its unlikely that a database will only have one client so you might get some
benefit from at least a data layer.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"David" <Da***@discussions.microsoft.com> wrote in message
news:73**********************************@microsof t.com...

I understand the need for n-tier architecture if an app is to be scaled-up
for server farm deployments. And I can also appreciate that separating UI
from business-logic from data-access is simply good design, if only from
the
point-of-view of "encapsulation" and functional layering.

HOWEVER, I'm having a hard time justifying to our devl staff (many of who
are 20+ year veterans, like myself), why in a "desktop" app which will
never
be deployed in a server-farm environment that we need to incur the
overhead
of having separate physical layers (be they web services or remoting).

And more specifically, why develop in a "stateless" paradigm, in which on
every user interaction we instantiate the BL which instantiates the DAL?
(as
Duwamish and other examples do).

Why not just have the "upper" layer instantiate the "lower" object ONCE
and
then hold that instance reference? Again, I fully appreciate why a
stateless
design is needed for server farms. But why incur the overhead of repeated
object instantiation/collection for a "desktop" app?

Or have we gotten to the point where the mere idea of a "logically layered
but physically monolithic" app is now heresy?

(BTW: is there a newsgroup that has a general but CONCRETE discussion of
n-tier practicality?)

Thanks,

David