Re: CRUD app interface

Don't those two things kind of relate to each other, particularly in a
simple CRUD program?

True you want to decouple those as much as possible however a simple CRUD
relies on the Model, so in the end the are about the same thing for the
purposes of this discussion.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Thu, Nov 8, 2018 at 3:09 PM Bob Cagle <bcagle@xxxxxxxxxxx> wrote:

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).

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com