views:

312

answers:

6

We are building three-tier architectures for over a decade now. Dividing presentation-, logic- and data-tier is supposed to allow us to exchange each layer individually, should the need ever arise, be it through changed requirements or new technologies.

I have never seen it working in practice...

Mostly because (at least) one of the following reasons:

  • The three tiers concept was only visible in the source code (e.g. package naming in Java) which was then deployed as one, tied together package.
  • The code representing each layer was nicely bundled in its own deployable format but then thrown into the same process (e.g. an "enterprise container").
  • Each layer was run in its own process, sometimes even on different machines but through the static nature they were connected to each other, replacing one of them meant breaking all of them.

Thus what you usually end up with, in is a monolithic, tightly coupled system that does not deliver what it's architecture promised.

I therefore think "three-tier architecture" is a total misnomer. The true benefit it brings is that the code is logically sound. But that's at "write time", not at "run time". A better name would be something like "layered by responsibility". In any case, the "architecture" word is misleading.

What are your thoughts on this? How could working three-tier architecture be achieved? By that I mean one which holds its promises: Allowing to plug out a layer without affecting the other ones. The system should survive that and be in a well defined state afterwards.

Thanks!

+3  A: 

One example of a 3-tier architecture is a typical database-driven web application:

  1. End-user's web browser
  2. Server-side web application logic
  3. Database engine
ChrisW
Is my answer wrong?
ChrisW
Actually I think at a high level this is what the poster is looking for. The 3 layers with well defined boundaries and interfaces. He's just looking for an example where it is all done within one process, I believe.
tloach
I thought he was complaining that because/when it *is* done within one process then it doesn't count: so this is an example of when it's done in separate processes (and often on three separate machines).
ChrisW
+3  A: 

The true purpose of layered architectures (both logical and physical tiers) isn't to make it easy to replace a layer (which is quite rare), but to make it easy to make changes within a layer without affecting the others (and as Ben notes, to facilitate scalability, consistency, and security) - which works all the time all around us.

Jeff Sternal
Totally agree. I'm just saying that the term "three-tier architecture" is misleading. It promises too much.
raoulsson
@raoulsson: I'm not sure that it does. The word "architecture" is singular--it's not "three separated architectures communicating via a generic, future-proof protocol"!
Ben M
@Ben M: Yeah. Could well be my own subjective misunderstanding in the first place...
raoulsson
+3  A: 

In every system, there is the nice, elegant architecture dreamed up at the beginning, then the hairy mess when its finally in production, full of hundreds of bug fixes and special case handlers, and other typical nasty changes made to address specific issues not realized during the design.

I don't think the problems you've described are specific to three-teir architecture at all.

whatsisname
A: 

Any operating system will have a similar kind of architecture, or else it won't work. The presentation layer is independent of the hardware layer, which is abstracted into drivers that implement a certain interface. The data is handled using logic that changes depending on the type of data being read (think NTFS vs. FAT32 vs. EXT3 vs. CD-ROM). Linux can run on just about any hardware you can throw at it and it will still look and behave the same because the abstractions between the layers insulate each other from changes within a single layer.

tloach
+2  A: 

Once you accept that n-tier's major benefits--namely scalability, logical consistency, security--could not easily be achieved through other means, the question of whether or not any of the tiers can be replaced outright without breaking the the others becomes more like asking whether there's any icing on the cake.

Ben M
How do you get scalability with a monolithic system? What you build is n-tiered, what you run is usually a bunch of apps that communicate sync and thus have the problem of the "weakest link".
raoulsson
I'll take a stab at answering that - an n-tiered architecture facilitates scaling when you design a system to distribute the processing load across its tiers and design the system so that its constituent components communicate asynchronously.
Jeff Sternal
+2  A: 

If you haven't seen it working, you may just have bad luck. I've worked on projects that serve several UIs (presentation) from one web service (logic). In addition, we swapped data providers via configuration (data) so we could use a low-cost database while developing and Oracle in higher environments.

Sure, there's always some duplication - maybe you add validation in the UI for responsiveness and then validate again in the logic layer - but overall, a clean separation is possible and nice to work with.

Corbin March