RE: A design philosophy question

> From: Booth Martin
>
> I agree.  This conversation is silly.  Labeling two bits of data
> in the same
> application as "unrelated" demonstrates just how differently you
> and I view
> data.

I hope you don't really believe that all data is related to the same degree.
How is a general ledger account description "related" to an item?  These are
unrelated pieces of data yet they may both need to be on the same inquiry
(typically a profitability report).  You need to use the item class (however
derived) to get the account number, and then get the company number to in
turn get to the correct chart of accounts so as to get the ledger account
description.  This particular logic obviously has no business in the general
ledger server.  It may tangentially belong to the item server, but only as
an external inquiry function.  It is really the combination of at least
three servers in my architecture: the item server (which could conceivably
return the item class information, though that's an issue), the company
server, which will return the chart of accounts ID, and the general ledger
server.

If you have a single server for this procedure, then you're either
duplicating code  (code, for example, for posting an amount to a general
ledger account), or else you're doing server-to-server calls.  The latter
is, in essence, what I spoke of as a presentation or data group server.

It is fundamentally different from a business logic server.  That's because
it really has no business logic, other than defining the relationships
between business classes.  Your approach (one server to handle all data
requests) only works when data is fairly simple.  When things get more
complex, you need more complex presentation logic, and that's what the
presentation server does.

But hey, if your code works for you in the real world, then I'm glad for
you.  I've always found that a presentation tier separate from my BL servers
makes it even easier to design systems.


> Further to that, I guess I really have no idea what a server is.

Not the way I think of them, anyway.


> I was not talking theory Joe.  I was talking nuts and bolts
> real-world stuff
>   So long as you slice vertically you are destined to a life of trying to
> gain performance through hardware solutions.  If you'll slice horizontally
> you'll see performance improve, your programs develop faster, and they'll
> live longer.

I wasn't slicing vertically, other than trying to figure out how to get the
same panel in two different applications.  You seem to think it's essential
to encapsulate all I/O in servers, yet it's okay to clone the DDS for a
subfile and all the server code supporting it.  Personally, I think that's
silly.  I think you can do both - create nice servers for presentation data
and at the same time share panels among applications.


> (by the way before you get to upset You are the one that chose "A design
> philosophy question" as the subject line, not me.   It sounds to me as if
> your questions are specific questions about implementation, not
> design. You
> ve already decided your design.)

No, I decided my architecture.  Green screen.  Multiple panels.  Multiple
display files, so panels can be shared among application programs.  That's
my architecture.  Now I'm trying to design the implementation.  You brought
up the issue of horizontal and vertical modularization, and how my
architecture doomed me, my users, and countless generations of maintenance
programmers <grin>.

Joe