Re: [OT] Is OO incompatible with the three tier architecture

From: Tony Marston (tony_at_NOSPAM.demon.co.uk)
Date: 08/14/04 

Date: Sat, 14 Aug 2004 00:50:21 +0100

"Average_Joe" <joe@geniegate.com> wrote in message
news:slrnchqd9v.ce8.joe@pong.tunestar.net...
> In article <cfi1f6$8m1$1$8302bc10@news.demon.co.uk>, Tony Marston wrote:
>>> I only see the N-tier stuff only in large scale applications that span
>>> several machines or need distributed access, (Ie: multiple presentation
>>> levels)
>>
>> I disagree completely. I think the idea of using different architectures
>> for
>> different application sizes is a totally bad idea.
>
> I didn't say it was a good idea, just that it's what I see. :-)

In my long career I have also seen a lot of things that were not a good
idea.

>> What happens if a small
>> system gradually grows into a large system? How can you switch
>> architectures
>> without rewriting the system? As a client I would not be happy if I was
>> sold
>> an architecture that could not be expanded.
>
> On the other hand, true N-tier stuff (Note that I didn't say '3') means
> "N-number of tiers" this can involve a lot of overhead code when it's
> time to split it across separate machines. Thats always been my
> struggling point. (Keeping it small and yet keeping it scalable)

I was once involved in a 10-tier system. The authors were so proud of what
they had done, so happy with their interpretation of the design rules. Yet
they missed one significant point - it was impossible to use this
architecure and develop components in a cost-effective manner. The customer
was so disgusted he cancelled the entire project before the first group of
programs was even released. I rewote the entire architecture and brought
down the development times from weeks down to hours.

> It is a worthy goal though.
>
> How did you handle these types of problems? (Keeping it small and yet
> capable of high scale)

I don't have a "small" architecture, a "medium" architecture and a "large"
architecure. I have a single architecture that covers small, mefium and
large. To make a system capable of handling more users you just need more
hardware, bigger hardware and faster hardware. When it comes to extra, extra
large systems then the design and integration of all the hardware components
is another skill entirely. I just stick to the software side.

> [tangent]
> Keeping them separate is kind of an interesting delima as well, take the
> LIMIT clause of some databases, very useful, but does LIMIT belong with
> the data tier?

I've had this argument before. Pagination is a function that spans all three
layers. The request for a particular page is received by the presentation
layer. It is passed straight through the business layer to the data layer.
As it is the data layer that handles all physical communication with the
database then that is the only place that can deal with the LIMIT clause on
the SELECT statement. The result is then passed back through the business
layer to the presentation layer where it is formatted for output.

Some people have the ridiculous idea that pagination is a function of the
presentation layer only, therefore the data layer passes back ALL available
records and leaves it to the presentation layer to sort out which ones to
display and which ones to reject. If your database table contained 100,000
records but you only wanted to display just 10 rows at a time then which way
is most efficient - use the LIMIT clause and read only 10, or read all
100,000 and filter out 99,990? Answers on a postcard please ....

> If I say to the business level "Give me so-and-so's account history"
> and, it's say 5,0000 objects/rows/iterations.. should the business logic
> be responsible for paging it for me?
> [/tangent]
>
>> If you design your architecture/infrastructure properly it should fit any
>> application of any size.
>
> I agree completely.
>
>> I spent 20+ years working in software houses where
>> we would churn out several new projects each year, and the advantages of
>> a
>> single architecture that could be used and used again became amazingly
>> obvious. Apart from the fact that you don't have to build a new
>> architecture
>> for each project, you also have less non-productive time when developers
>> switch from one project to another as there is no need for a huge
>> learning
>> curve.
>
> My opinion is that PHP is a poor choice for working around too much in the
> business logic side. It would make an excellent presentation layer
> though.

I disagree. PHP is no worse than any other language for dealing with
business logic, and I have used a variety of 2nd, 3rd and 4th gneration
languages in my time. In my long experience the choice of language comes
second place to the skills of the development team. A second rate programmer
will always produce a second rate result regardless of the language.Concepts
don't count if the implementation is crap.

> The single archetecture is a nice idea, one I try to use as well. I
> guess I sometimes get bored with it though, always want to try new
> things. :-)

I get my kicks by developing a modular system, then whenever a new feature
comes out I find I am able to incorporate it into my system with the minimum
of fuss. I am always tuning and polishing my system which is why it is
efficient and up-to-date. I have seen too many examples where an
architecture is never updated when new features are made available which
means that it eventually becomes obsolete. It then means that to take
advantage of the new features the entire system has to be rewritten, and
some people (usually non-technicians) make the decision to rewrite it in a
new, more fashionable language where the whole cycle starts all over again.
Some people never learn. 

-- 
Tony Marston
http://www.tonymarston.net

Relevant Pages

  • Re: OBJECT-ORIENTED LAYERED ARCHITECTURE AND SUBSYSTEMS
    ... > OBJECT-ORIENTED LAYERED ARCHITECTURE AND SUBSYSTEMS ... > requirements of system owners, users, and clients. ... > code modules which all carry out the same necessary tasks for a layer. ... > each of those areas, or domains, constitutes a subsystem. ...
    (comp.object)
  • OBJECT-ORIENTED LAYERED ARCHITECTURE AND SUBSYSTEMS
    ... OBJECT-ORIENTED LAYERED ARCHITECTURE AND SUBSYSTEMS ... project's physical design, and implementation. ... code modules which all carry out the same necessary tasks for a layer. ... each of those areas, or domains, constitutes a subsystem. ...
    (comp.object)
  • Re: Some architecture advice
    ... > I've used business objects for a while, ... > make apps that are more maintainable. ... each layer is independent of one another and each ... > Being relatively inexperienced with architecture I'm sure ...
    (microsoft.public.dotnet.framework.aspnet)
  • ASP.net application architecture and design questions
    ... I often read about a 3-tier architecture consisting of a presentation layer, business logic layer and a data access layer. ... Should the BLL be separate from the web application? ...
    (microsoft.public.dotnet.framework.aspnet)
  • Layered OO System Architecture & Why Dip Is Errant
    ... Extended Discussion On Layered OO System Architecture ... A system layer is able to compile, ... Having each layer use abstract interfaces, ... policy" and that classes which implement abstract interfaces are "low ...
    (comp.object)