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 / \
--------------------------------------------------------------------
midrange.com
