× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Externalize DB/IO (was What Counts as Technically Slick?)
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Tue, 10 Apr 2001 03:26:44 -0500 (CDT)



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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.