Re: Externalize DB/IO (was What Counts as Technically Slick?)

On Mon, 9 Apr 2001, Nathan M. Andelin wrote:
> 
> http://www.ignite400.org/news/news2001030901.htm
> 
> Scott,
> 
> That's a link to an article by IBM's Phil Coulthard.  It endorses the
> Model-View-Controller architecture that we're essentially talking about.
> 
> While it may be unlikely that the database is moved to another platform,
> what about User Interface?  Can you imagine a single DB/IO module supporting
> a 5250, HTML (browser), and WML (Palm Pilot), and XML (Web Services)
> interface?  I can!
> 
> Nathan.
> 

Lest we be talking about different things here, let me elaborate.

The original poster was complaining of someone writing a "server" program
to read/write/update records for a file.  (I don't really like the use
of the word server here, but that's the way it was stated originally.)

What I'm arguing against is adding unnecessary layers of complexity to
programs that accomplish nothing.

Replacing code like this:

C     KeyList       Chain     MyFile
C                   if        not %found
C                   endif

With this:  (plus the appropriate prototypes, service programs, etc)

C                   if        Not ChainProc('MYFILE': KeyList: Record_ds)
C                   endif


Is what I'm saying is a bad idea.   The reason is because the added
complexity of having the extra service program, etc, is buying you nothing
if all the "ChainProc" does is CHAIN to the file, just like the RPG
op-code does.

I'm simply saying that mimicking the behavior of existing RPG op-codes is
a bad idea.   Sure, you could move all the actual file I/O into a seperate
program or service program to avoid getting level check errors, etc.  But
the result would be something no safer than compiling your files with
LVLCHK(*NO)!  

I'm a big fan -- and supporter -- of modularization in general.   As long
as it serves a PURPOSE.  If your routines will be a higher-level routine,
with built in & reusable business logic -- then they make perfect sense to
me.

I agree that the user interface logic should be split off from the
business logic, in many cases.  (This can be a major pain to do, though --
requires very careful planning!)  This is PARTICULARLY true for software
companies creating products to be distributed to many customers. 

In a small shop like mine, where the software is only used in-house, this
seperation is less important.



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---