RE: CRUD app interface

You guys keep talking about the M in MVC. While this is a good topic of conversation, I was really only asking about the V.

Thanks

Bob Cagle
IT Manager
Lynk


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Booth Martin
Sent: Thursday, November 8, 2018 11:58 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: CRUD app interface

This is the angle I was going for when I mentioned web services.
Creating and duplicating data relationships, business rules, and authority rules with every new fad that comes along, and every new line manager's biases and whims, is a self flagellating exercise. In my opinion.

Why not provide a singular solution that allows all those new things to happen without having to worry about keeping a bunch of more-or-less duplicating systems synched.  Trying to solve the same problems a half dozen different ways seems to me to be a good way to start fights in the lunch room.


On 11/8/2018 11:10 AM, Nathan Andelin wrote:

On Thu, Nov 8, 2018 at 7:05 AM <JRusling@xxxxxxxxxxx> wrote:

Yeah, it's kinda slick, i like it.

I agree that CRUD utilities are slick, in a way. But I think that
people should understand that they fail in regards to most functional,
user experience, and database integrity requirements.

When we expose database read, write, update, and delete capabilities
through a user interface, those operations should be backed up by
logic that ensures end-user access authorities, database integrity
constraints, the implementation of database-I/O related business
rules, error handling, along with messages worded in a way that is meant for human understanding.
When database update operations fail due to field-level validation,
the field should be highlighted, and the cursor placed in the input element.

I wrote about that type of logic in the following article:

http://rd.radile.com/rdweb/info2/ibmiapp04.html

Which suggest that database I/O related logic should be placed in
database event procedures, having names such as:

on_read()
on_write()
on_update()
on_delete()

They should be written in a language like ILE RPG, which runs in the
same address space as the DBMS, and can perform record-level operations.
Although the part of the CRUD application that performs browser I/O
may be written and run in various language environments, I would still
assert that at least part of it - the part that actually performs RLA
operations should be written in an ILE language.

Which suggests that if one chooses to use a non-ILE language, and
language environment, then that part of the application should be
coded in such a way that it is able to interface with the back-end
part, which is performing the actual DB I/O, and the part that
responds to database events (read, write, update, and delete).