in reply to [swengr] Componentizing Complex Apps

A couple of points I don't understand:

  1. Why is using object-oriented Perl an entirely separate manner of organizing a large project? Any one of the three preceding categories could be implemented using OO Perl, or non-OO Perl, or C, or lisp, or ... .

  2. Are tiered and client/server really that distinct from one another? It is common to speak of n-tier client/server applications (I'm working on one now). It seems you mean to say that a tiered application must reside on a single machine, whereas only client/server apps are allowed to communicate over the network. To me, a tiered system is one that horizontally abstracts functionality into, for example, a database, a database access layer, a business layer, and a presentation layer. A client/server system utilizes interprocess communication possibly over a network to enable one program to invoke commands in another. But these are certainly compatible ways of organizing an application, and in fact together they provide a solution for your signal-handling worry.

  • Comment on Re: [swengr] Componentizing Complex Apps

Replies are listed 'Best First'.
Re: Re: [swengr] Componentizing Complex Apps
by princepawn (Parson) on Dec 02, 2002 at 17:06 UTC
    Why is using object-oriented Perl an entirely separate manner of organizing a large project? Any one of the three preceding categories could be implemented using OO Perl, or non-OO Perl, or C, or lisp, or ... .
    Hmmm, good point.

    It is common to speak of n-tier client/server applications (I'm working on one now).
    Hmm, so what I have is a type of tiered application. A inward spiraling tier: program A calls B calls C which does the inner work then we pop back to B then back to A.

    Thanks for your comments. I had hoped to generate a lot of discussion.

    Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality