Diff between 'n-tier' vs 'distributed architecture' vs. 'multi-layered programming'?

[Jon Davis]

I have a couple questions. First of all, would anyone consider a
multi-layered programming approach (building business objects that are
seperate from data access logic and seperate from user interface logic but
that interface the UI and the data) an n-tier implementation by definition?
Or does n-tier necessitate a network-distributed architecture (beyond IIS
and SQL Server, i.e. COM+/MTS/MSMQ/WCF) in addition to the layered
programming? If a solution is properly broken up into its distinct layers,
does this qualify as 'n-tier'?


Additionally and more broadly, ...

- "n-tier"
- "3-tier"
- "distributed architecture"
- "multi-layered programming (UIL, BLL, DAL)"

I'm finding a lot of confusion among managers and software engineers
throwing these terms around interchangeably. I have my own opinion about
these--how they relate and how they are distinct--but I was wondering what
the opinions are of others in this newsgroup community. Any thoughts?

Thanks,
Jon

 

[Carl Daniel [VC++ MVP]]

I have a couple questions. First of all, would anyone consider a
multi-layered programming approach (building business objects that are
seperate from data access logic and seperate from user interface
logic but that interface the UI and the data) an n-tier
implementation by definition? Or does n-tier necessitate a
network-distributed architecture (beyond IIS and SQL Server, i.e.
COM+/MTS/MSMQ/WCF) in addition to the layered programming? If a
solution is properly broken up into its distinct layers, does this
qualify as 'n-tier'?

Additionally and more broadly, ...

- "n-tier"
- "3-tier"
- "distributed architecture"
- "multi-layered programming (UIL, BLL, DAL)"

I'm finding a lot of confusion among managers and software engineers
throwing these terms around interchangeably. I have my own opinion
about these--how they relate and how they are distinct--but I was
wondering what the opinions are of others in this newsgroup
community. Any thoughts?

IMO, they're mostly synonymous. I would imagine that many people don't
consider a design to be n-tier unless the layers are isolated service
processes (which may or may not be distributed to multiple machines).
Personally, I find that distinction to be irrelevant in most cases - if a
design has be properly separated into loosely coupled, highly cohesive
layers, then the distribution of those layers to isolated service processes
or separate machines is a straightforward, well-solved problem (.NET
remoting, SOAP, etc.).

-cd

 

[Cor Ligthert [MVP]]

Jon,

Of course, but not as a Tier application but as a layer application.

In other words the layers exist on the client as an integrated assembly and
not as more assemblys as with a multi Tier application.

Just my thought,

Cor

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I have a couple questions. First of all, would anyone consider a
multi-layered programming approach (building business objects that are
seperate from data access logic and seperate from user interface logic but
that interface the UI and the data) an n-tier implementation by definition?
Or does n-tier necessitate a network-distributed architecture (beyond IIS
and SQL Server, i.e. COM+/MTS/MSMQ/WCF) in addition to the layered
programming? If a solution is properly broken up into its distinct layers,
does this qualify as 'n-tier'?

Additionally and more broadly, ...

- "n-tier"
- "3-tier"
- "distributed architecture"
- "multi-layered programming (UIL, BLL, DAL)"

I'm finding a lot of confusion among managers and software engineers
throwing these terms around interchangeably. I have my own opinion about
these--how they relate and how they are distinct--but I was wondering what
the opinions are of others in this newsgroup community. Any thoughts?

I am old fashioned:

tiers = something that can but not necessarily do run on
different physical systems

layers = logical division within a tier

so you can have 3 tiers:
browser
web app
database

where the web app has 3 layers:
presentation
business logic
data access

Many people (especially within MS technology) uses the term
tier for what I am calling layer.

Which I think confuses matters a bit.

But by using the old definition I think all your questions
is rather easily answered.

Arne

 

[Michael S]

I am old fashioned:

I think you quite modern and right on target.
The definitions you gave below are correct.

Many people (especially within MS technology) uses the term
tier for what I am calling layer.
Which I think confuses matters a bit.

I never seen ms get it wrong.

Happy Tiers and Layers
- Michael S

 

[Jon Davis]

I never seen ms get it wrong.

http://msdn.microsoft.com/asp.net/r...html/aspnet_tutorial01_dataaccesslayer_cs.asp

The link to the above URL originally on the MSDN home page and currently in
Visual Studio 2005 Start Page is clearly labeled "3-tier Architecture with
ASP.NET 2.0", but this is clearly a programmatic layering discussion without
respect to physical isolation.

Jon

 

[Cor Ligthert [MVP]]

Jon,

I completely agree with Arne, the meaning of my reply was the same,

I have forever had the idea that the Tier part on MSDN is written by the
marketing department of Microsoft. The Tier philosophy is a part of central
processing with 3270 or VT100 processing and not for real advanced
Client/Server processing, as it is done with Windowforms applications.

However, just my idea,

Cor

 

[Michael S]

Well, maybe they got the terms wrong with layer and tier, but not the idea.
They still got the concepts right, and don't mix them.

I've read a book from microsoft press that got all normalforms in
datamodeling wrong by one notch. Hence their second normal form was the
third (or was it first), all this while giving examples that held true for
the correct form.

So maybe I shouldn't defend ms, but go back to only say that Arne was
correct in his definitions.

But to help the OP

Jon: You should check out SOA, and why the typical 3-tier/3-layer
architecture people was used to in COM and VB; just don't hack it no more
and make for a troublesome architecture.

If you want to learn why SOA may be good and want to read for yourself,
please do. But I am willing to write a few paragraphs on the subject if you
want me to. Partly to help you, but mostly for my himem.sys joke, that
people got really angry about, and by so; I need some redemption.

But this thread is getting old so you must say ping.

Happy Architecture
- Michael S