RE: A design philosophy question

--
--
[ Picked text/plain from multipart/alternative ]
Joe you miss my point.  In the example you pose I would write a single
program with no user interface.

That one program gets all the data, checks it, applies Business Rules,
whatever  is needed.  That program is secured and can not be accessed
directly by any user.  The fields (certainly far more then the 5 bits of
data you suggest) would populate a Data Structure.  The data structure would
also include an error message field.  For example if the user has asked for
5 pieces, yet the Business Rules say that we can only sell that item in lots
of 6, there has to be a message sent to the user.

Further, that program would just do the Order Line.  Another program would
do name & address processing, (and only name & address).  Yet another
program would process shipping information and apply the Shipping Department
s Business Rules. Another program might deal with Special Promotions,
Inserts, Seasonal Items, or even send comments to the user about related
items to mention to the buyer.  In this manner, each piece can be developed
and refined department by department without destroying any of the other
pieces.

To continue with your example: Your presentation program could place the
fields in any order, but that's part of the presentation.  Your presentation
layer also has to handle the error message,  You need to tell the user the
Quantity must be in multiples of 6, for instance.  I would see no reason for
the presentation layer to ever be allowed to access raw data, let alone read
data from several different servers.  My gosh! you are back to the old
monolithic model when you do that.

By the way, we may see Business Rules in a different way.  I see Business
Rules as being the Business's rules, unrelated to computing.  It includes
things such as A/R Credit Limit testing, pricing rules, discounting,
purchase order requirements, geographic constraints, or what ever the boss
says we shall do.

In my example, if there were a name & address program written, then never
again should a programmer include a name-address F-Spec in any program he
writes.  If he tries to, it should fail because no user should have
authority to the library containing the actual data.


---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@MartinVT.com
---------------------------------------------------------

-------Original Message-------

From: rpg400-l@midrange.com
Date: Sunday, September 29, 2002 06:57:28 PM
To: rpg400-l@midrange.com
Subject: 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

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

.
--
[ Content of type image/gif deleted ]
--