Mr. Byrne writes:
> We have commenced the process of moving from MPE/POWERHOUSE/IMAGE to
> Linux/RubyOnRails/PostgeSQL.  While we have a very, very long way to
> go before coding the debate over whether to place most, or at least
> as much as possible, of the system logic (business rules) into the
> DBMS in the form of SQL triggers and procedures or to place much of
> this in application code has already begun.  The reason that I am
> asking this question here is that posing it on the forums that deal
> primarily with the tools in question seems to produce emotional, or
> at least casually presumptive, responses rather than deeply
> considered reasoning.

The question one might ask is why will this be a very, very long process?
You are coming from a system that mixes the MVC components freely. It always
seemed to me that good MVC shouldn't give a lick about the implementation
details. If our MPE/Image/(Cobol/Fortran/Basic/PowerHouse) systems really
separated the data from the views from the business logic, this task would
be much easier for you. Agreed?

> My own prejudices lean me towards incorporating as much business
> logic into the DBMS as the software will handle, and then some.  What
> supports this belief for me is my estimation of the reliability and
> efficiency benefits realized by centralizing things like field edits,
> comparative values, logical references and automatic recording of
> audit data like userids and timestamps. Doing this sort of stuff at
> the database level eliminates a great deal of necessarily repetitive,
> and therefore tedious and error-prone, coding in the application and
> restricts potential sources of application data corruption.
> Embedding SQL code into the database itself seems to me the most
> robust form of controller possible in the MVC scheme of design.

The goal of any good MVC design is to have the ability to switch out
different implementations and still have your system work. If so, you should
be able to swap out PostgreSQL with mySQL or Oracle just by changing the
implementation of your model. If there's enough abstraction in your
controller, you shouldn't have to make any changes there. In your Ruby
controller code, one should never see any mention of stored procedures or
triggers or PostgreSQL - only calls to routines that implement them. Those
routines should document what is going on in the stored procedure so if
another person were to try to move this package to a different data store
(Oracle, ISAM, XML ...), they could replicate the rules in another database.

I guess my point is that you should be able to have your cake and eat it
too. The point of MVC is to get people to think about programming to
abstract interfaces that can be flexible enough for different
implementations. In a conversation I had with Fred White, he said there is
no such thing as relational, network, or hierarchical databases; there's
just relational, network, or hierarchical interfaces to data stores. If we
always program to the interface, i.e. keeping all the rules in one place, we
also remove the potential sources of application data corruption.

> If you feel that the question travels too far afield from legitimate
> topics relating to the HP3000...

You're joking, right?  ;-)

Google turned up some links you may want to consider:

Introduction to Model-View Controller Architecture Using SQL Stored
Procedures (Using an iSeries!)
http://www.ocean400.org/SHoffmanMVC06212005.pdf

Introduction to Object-Oriented Tiered Application Design
http://codeproject.com/gen/design/TieredDesign.asp

Mark W.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *