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 11:10:16 +0100


"Average_Joe" <joe@geniegate.com> wrote in message
news:slrnchqsql.lvv.joe@pong.tunestar.net...
> In article <cfjk3u$sk5$1$8302bc10@news.demon.co.uk>, Tony Marston wrote:

<snip>

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

I am not "forgetting about reality and concentrating on the model" because
reality dictates that you use the LIMIT option which is can only be
generated by the data access layer. In the "ideal" world some people want to
see all pagination functions limited to the presentation layer, but this
produces an extremely inefficient result. The ideal solution as far as the
customer is concerned is the most efficient solution. Any methodology which
produces inefficient code is one to be avoided.

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

The lack of a compiler is not a problem for the vast majority of people as
the scripts run "fast enough", which is the only measurement worth talking
about. The semi-compiled option with page caching is available via
commercial products. If you have a system that really *needs* those features
then you can surely afford to pay for them.

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

All I can say is that I have had no problem with using PHP in the middle
layer. What functionality do you think is missing? Where is PHP deficient?

> 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 have used PHP to create web-based versions of applications which I
previous wrote in other languages, and I have to say that the results are
far superior. The power and flexibility of PHP has enabled me to develop a
powerful and flexible architecture, one in which I can develop components
faster than I could before.

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

But Java coders tend to be much more expensive than PHP coders, which is
something that employers should seriously consider. When it comes to
developing web applications you (and everybody else) should note that even
the authors of Java have conceded that PHP is far more efficient at
generating web pages, which is why Sun Microsystems and Zend are working to
make PHP and Java more interoperable (see
http://www.zend.com/news/zendpr.php?id=63).

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

I've been there before. Sometimes management will decide to switch to
another language simply because it is more fashionable, yet unless you have
a team of competent designers and developers any language can yield less
than optimum results.

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

That's where XML is making inroads as this is a standard way to exchange
data between systems written in different languages. This avoids the need to
write custom interfaces which is the cause of most problems.

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

Having experience of more than one language is always a good idea, but
sometimes an employer will not take advantage of it. Some big companies are
still using COBOL for the simple reason that they have so much code written
in that language that they simply cannot afford to rewrite it. All the while
they can find enough COBOL programmers and the language is updated they see
no reason to change.

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


Relevant Pages

  • Re: my little comments on jsp and php
    ... I learned jsp for about 5 years, and learned php for about 4 ... You need to do the same with regular Web apps on any server. ... I have made many Java projects using the identical build.xml. ... presentation layer, logic layer, data layer. ...
    (comp.lang.java.programmer)
  • my little comments on jsp and php
    ... I learned jsp for about 5 years, and learned php for about 4 ... I feel php is more easy to learn, and it can do almost java ... presentation layer, logic layer (struts), data layer. ...
    (comp.lang.java.programmer)
  • 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: my little comments on jsp and php
    ... I learned jsp for about 5 years, and learned php for about 4 ... I feel php is more easy to learn, and it can do almost java ... presentation layer, logic layer (struts), data layer. ...
    (comp.lang.java.programmer)

Loading