Re: Service programs and QSRVSRC

When I said single point business logic I don't mean one program that do
every business logic for your entire business application. What I means
is a single executable that will allow multiple processes to validate or
process request. So, order entry will have a Order Entry (Model) as a
executable and sales order will has its own Model as a execuable also.

Using your example, I would think is would be much better to make
OEMODEL as a service program or program. Why make it a module. If you
make it a service program and if you need to change some business
logics, you can simply change the service program without having to
rebind them and gurantee both process using the exact same OEMODEL.



"Simon Coulter" <shc@xxxxxxxxxxxxxxxxx> wrote in message
news:<mailman.6841.1255644662.1811.rpg400-l@xxxxxxxxxxxx>...

On 16/10/2009, at 7:21 AM, Lim Hock-Chai wrote:

In MVC arrangement, the M, V, and C are typically executable

objects.

That depends entirely on the environment in which you're building
things. MVC originated in Object Oriented Programming where each of M,

V, or C is a class and therefore is an executable object. That's just

an artefact of the environment (Smalltalk, Eiffel, Java, etc.). There

is no reason why MVC cannot be implemented using modules in a non-OO
language.

I never see M, V, and C as modules. One of the main purpose of MVC

is to
allow single point business logic (the M). I'm not understanding

the

concept of creating them as module.

The business logic for sales orders is different from the business
logic for resource planning. There is no reason why they would be in
the same M therefore implementing them in separate modules makes

sense.

Even if you want to do it as
module, what is the different between making them a *SRVPGM vs

*MODULE

or just make them become one single *module if you know that no

other

program will ever need to bind each individual *module?

You're missing the whole point.

The screens for order entry are specific to order entry and will be
used nowhere else. The logic for order entry is specific to order
entry and will be used nowhere else (there may be common validation
which should be in a service program but the core is specific to order

entry). Raw database access to files is common and should be in a
service program but the way, or sequence, in which those routines are

invoked is specific to order entry. Thus, it makes sense to have a
module for OE screen handling, another for OE logic, and another for
OE data access.

If I divide these functions into separate modules (e.g., OEDSPF,
OEMODEL, OEDATA) and bind into a single ORDENT program then should I
ever need to put order entry on the web I can create a new module
(OEHTML) and then bind OEHTML, OEMODEL, OEDATA into a new program
called OEWEB. I have immediate reuse of two existing modules neither
of which need know anything about how the interface with the user is
implemented.

If I do the traditional monolithic RPG program from single module with

embedded screen and data I/O then to create the web variant I have to

clone the single source member, rip out all the DSPF stuff, replace it

with web stuff, deal with all the assumptions and interrelations
caused by having MVC in the same module.

Even if I don't **know** now that I might need to reuse these modules

in a future environment, by separating according to MVC I make my code

more reusable than it might otherwise be. The cost of doing so is a
minor increase in complexity and a significant increase in design
effort, both of which are far outweighed by the flexibility inherent
in such an approach.

I could package at least some of the modules in a service program
instead of bind-by-copy and I may choose to do so depending on how I
envisage it being used. It makes no real difference to this
discussion--you still have separate modules implementing a given
process.

You (and others) may not agree with me but as anyone who has seen my
past comments knows I don't really care about that. I have outlined a

valid reason for using multiple modules in a single object which
addressed your original comment that you could not "think of a
situation where (you) would want to create a program using multiple
*MODULE".

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------