RE: A design philosophy question

> From: Booth Martin
>
> You are quite right. This info comes from different places and
> all sorts of
> factors in all variations from customer discount to delivery and
> availability are involved.  Why do you say this is part of the
> presentation
> process?  I do not see it that way at all.

Because different programs will need different combinations of data.  That's
the point of presentation.  Presentation pulls together the data into a
model from various BL servers.

Now, if you're advocating writing an individual server for each model, then
you're into a completely different architecture.  The BL server contains
rules about how data for a specific business object is stored, accessed and
updated.  The presentation server accesses multiple business servers to
present related data to the user.  VERY different roles, and they should not
be confused.

Let's take an extreme example.  There are 5 different bits of data, totally
isolated, each served by a different BL server.  If we use just simple
combination logic, there are 31 possible combinations of this data being
displayed on a line, not factoring in ordering by column.  So are you
advocating 31 servers?  I should hope not.  Instead, how about a
presentation server with 31 different opcodes and 31 different data
structures?  Or do you always fetch all five bits of data into a single
structure, even if they aren't used?  Or do you have a single data structure
that only selected fields are filled in based on the opcode?

Next, if the fields in the line are updatable, does your application simply
send the data structure back to the presentation server, who in turn passes
the updates through to the appropriate BL server for each separate bit of
data?  Interesting possibilities here.  A little complex, but certainly
doable.  The problem lies when you have rules specific to multiple updates
(such as circular bills of material), but in general an interesting
approach.

Now, expand this.  One of the bits of data is also displayed in a different
application, along with three other data bits unrelated to the bits in the
initial application.  Do you write another server with 15 opcodes, with the
ability to invoke the four BL servers as needed?  Again, I can see it, but
it's a level of complexity a little higher than what you're suggesting.  And
any rules regarding multiple updates for the bit that appears in both
servers must be modularized so that it can be invoked via procedure call in
both presentation servers.

In order to totally insulate the presentation logic from the BL server,
you'll need an intermediate layer of data group servers, each responsible
for the gathering of data from individual BL servers.  I like this approach,
if I have the time to write it.


> I hope that my answer doesn't seem simplistic or silly.  I really
> do believe
> our future lies in horizontal, not vertical modulaization.

You're preaching to the choir on modularization, but it's not as simple as
all that.  THERE IS NO SILVER BULLET.  If you properly design your systems
and group your data into logical related entities, then you can probably
create the presentation server tier I've outlined above, which effectively
isolates your UI from your business logic.  But it's not as simple as
designing a server every time you have a new subfile, otherwise you end up
with a ton of different servers duplicating the same logic.


And in any event, you still haven't addressed my issue.  I have the same
subfile in two different applications.  I don't want to clone the subfile
record formats into two different display files; that's absolutely
antithetical to this entire discussion.  Instead, I'd rather modularize the
presentation logic.  How do I go about that?


Joe