473,326 Members | 2,102 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

n-tier performance trade-off (guidance needed)

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
Jul 21 '05 #1
3 1599
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

Jul 21 '05 #2
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

Jul 21 '05 #3
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

Jul 21 '05 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Ken Fine | last post by:
I would like some guidance regarding a "content scanner" I'm trying to build. This ASP widget will automatically scan remote web sites for certain kinds of content using a screen scraping component...
2
by: bostonmegarocker | last post by:
Hi to all? For the past couples of weeks I have been programming to make a program that reads a binary file and produces the equivalent text file. The idea is that each byte in the file...
0
by: jaggee | last post by:
Hello, This is regarding log analysis of a web system, I am finding my backend SQL programming has taken so much of time to process the application due to following quires for a log table having...
6
by: David | last post by:
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...
0
nirmalsingh
by: nirmalsingh | last post by:
hai everybody, i am new to php. i have no idea to generate web based reports. i even dont know, where to start, how to display it and etc., i am seriously in need of guidance. plz guide me the way...
3
by: Alan Isaac | last post by:
This is a simple question about actual practice. I just want to know how you (yes you) are approaching this problem. The problem: What is the recommended packaging of demo scripts or test...
2
by: r2d3 | last post by:
Hello, New to Oracle (9i), so hope some one can understand and help with this. I want to add a episode number to a table, which will give the sequence of each episode. (Sorry for using the word...
1
nirmalsingh
by: nirmalsingh | last post by:
hai all, i am new to asp.net, but i am eager to learn more about web services and to implement more effectively in projects. can any one suggest me an online tutorial with sample code and examples...
2
nirmalsingh
by: nirmalsingh | last post by:
hai all, i am new to charting or graph. is there is any control to display a chart report? or how should i display report in chart format? can anyone guide me, thanx in advance with Cheers ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.