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

From: Average_Joe (joe_at_geniegate.com)
Date: 08/14/04 

Date: Sat, 14 Aug 2004 02:18:11 GMT

In article <cfjk3u$sk5$1$8302bc10@news.demon.co.uk>, Tony Marston wrote:

> 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.

I once designed an N-tier (truly N-) It had 3 basic layers, however
everything was thought of as a "service", so, you had a "business logic
service" SMTP "service", etc.. Probably the best design I've ever done.

Was kind of neat, because the services were kept in LDAP, you could add
or remove hardware on demand, without shutting down the rest of it.

The downside was that, while in theory you could run all the services on
1 machine, you really wouldn't want to. Scaling something like that down
to where it runs on a single PC, along other applications, would have
been a nightmare.

I think the network RPC stuff is really what helped me stay focused on
keeping the layers separate. (It is also part of what made it so large
though)

> large systems then the design and integration of all the hardware components
> is another skill entirely. I just stick to the software side.

Seems to me you almost HAVE to pay attention to the hardware end if
you've got distributed applications. Problem being that networked
filesystems (among other things) can be a point of failure, so you try
to make do without them.

> 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.

On a practical "real-world" basis, I totally agree. (A fact I've learned
the hard way..)

> 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 ....

But, it leaves the "idealistic" question open, aside from "It's done on
the business level because the database is the only place it CAN be
done", put yourself in a more "lets forget about reality and
concentrate on model" In that more narrow context, where does pagination
belong? I can see where it's easy to get caught up.

>> 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.

Without package support and a lack of a compiler (negating the
commercial ones available) The near inability to cache objects in pools
and so forth between requests. (the only way I can see how to do this
would be to write actual server code in PHP)

I'd have to stand by my opinion that PHP is generally a poor choice for
the middle layer, which is just fine because it excels in the area it
was designed for.

Thats not to say a horrible design in Java or C++ would beat a well
design in PHP, it's just to say a good design in <Insert_Other_Language>
would probably beat a good design in PHP. (When it came to a markup
based presentation system, I think PHP would rock over most of the others
though)

> 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.

I think some of the reasons the business types pick a more fashionable
language has to do with market demand. Java coders are/were very easy to
find, so people pick Java. As a perl coder I was pretty disgusted when
the company I worked for decided to move everything to java. (We were a
perl place originally) Part of the reason was that more employees were
coming on board with Java backgrounds.

Nowadays, I like to work in multiple languages because I've found that
they have their strengths and weaknesses in different areas. I predict
(hope) we'll see more stuff written in several languages.

Would you get bored with 1 single language? I realize most languages
are constantly evolving with new features and such, that it's almost
impossible to actually master any of them, so I guess I could see where
someone may be satisfied with one. (I've used perl for many years and
still haven't "mastered" it, heck, I doubt even Larry Wall did.)

Jamie 

-- 
http://www.geniegate.com                     Custom web programming
User Management Solutions                   Perl / PHP / Java / UNIX

Relevant Pages

  • Book Recommendations Request
    ... the language, nor explain OOP, but rather present real-world scenarios ... Programming - Problem, Design, Solution" by Marco Bellinaso (ISBN: ... Layer), and creating and implementing these layers using correct OOP ...
    (microsoft.public.dotnet.languages.vb)
  • Book Recommendations Request (VB.NET 2005)
    ... the language, nor explain OOP, but rather present real-world scenarios ... Programming - Problem, Design, Solution" by Marco Bellinaso (ISBN: ... Layer), and creating and implementing these layers using correct OOP ...
    (comp.lang.basic.visual.misc)
  • Re: [OT] Is OO incompatible with the three tier architecture
    ... It is passed straight through the business layer to the data ... In my long experience the choice of language comes ... > would be to write actual server code in PHP) ... Java coders are/were very easy to ...
    (comp.lang.php)
  • Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]
    ... Linux community has less patience for design flaws that PHP's success ... Apart from the masochists who run PHP ... secure than they will a scripting language, but syadmins, the people ... both in security and stability. ...
    (Bugtraq)
  • Re: [PHP] Beginner Tutorials for using CLASSES in PHP4
    ... fancy design patterns just because design patterns are supposed to be ... But you are the one who pointed out that interfaces are used in design ... PHP is different, therefore the solution will be different. ... force it into emulating another language. ...
    (php.general)
Loading