Thanks for the reply, Scott. Not to interrupt or detract from anyone's Independence Day celebrations, but I have enough time to reply before leaving for our local parade.
I've been working on a set of service programs in conjunction with this thread, and also put together a fairly trivial screen to test the interface. I haven't done much testing. Hopefully it doesn't break while I'm out:
http://www.radile.com/rdweb/temp/names.html
There's a link to the RPG program, but the code is pretty terse. The API is intended to be high-level, with programmer productivity in mind, but also flexible. I'll briefly explain some of the procedures.
csrNew() - creates an instance of an SQL Cursor and returns it's reference. The cursor may be based on a file name or SQL view name (a view may be used to define result sets from multiple tables, for example).
csrSetOrder() - specifies the columns to order a result set by.
csrSetFilter() - specifies a filter criteria.
csrRequery() - generates a result set.
wtnAction() - retrieves browser requests based on the subject at hand.
wtnRowWrt() - maps result set columns to the client based on a template. There's actually a lot of work going on behind the scenes, such as data type conversion, and output formatting based on file field definitions.
wtnMsgWrt() - sends a message to the client.
I hope this example clarifies what I've been thinking. And some of it's R&D at this point. Feel free to critique. I may be missing a "business" layer, for example.
Nathan.
----- Original Message ----
From: Scott Klement <web400@xxxxxxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Thursday, July 3, 2008 12:07:04 PM
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers
Hello,
I understand that SQL is used for database updates in many
environments. And that database updates are subject to business
rules and methods. And that under an object oriented runtime there's
good rationale to incorporate business rules and methods into
business objects.
I'd say that this holds a great deal of value in any environment
(whether object oriented or not).
And as far as I know, SQL doesn't support
"records" in the same context that RPG does. But what is the appeal
of embedding "result sets" in business objects?
The reason you add the business rules layer is because it encapsulates
the business rules, and creates a layer of independence.
Whether you're creating a web app, green screen app, or something else
(perhaps an app that reads all of it's input from a file or maybe an XML
doc) should be immaterial to the business rules. You should be able to
re-use the same business logic no matter where the input comes from or
the output goes to. The way you achieve that is by making sure the user
interface knows nothing about the business logic, and the business knows
nothing about the user interface.
I think Walden's reaction to your message was because you were having
the display layer directly access the database -- i.e. the display layer
knew how the business rules were implemented (i.e. they were implemented
with database logic)
Along the same lines is independence. Perhaps you're using a database
today, but maybe next year you'll decide to store your data in an XML
document. (The user interface shouldn't care.) Or perhaps five years
from now, you'll want to outsource your data storage to another
machine's database, or even another company, and your business rules
will now need to run an SQL query against an Oracle database or a MySQL
database or call a web service. The point is, the application shouldn't
know or care how the data storage is implemented. And the storage of
data is part (but not all of) your business rules.
Whether it's object-oriented or not, and whether your business layer is
called a "business object" or not, they should be kept separate. At
least, in a perfect world.
On the other hand, if you are providing tools who's job is database
analysis -- then it's hard to apply a "business rule layer" since the
stated goal is to work with the database, not to conduct business.
It really depends, I guess, on whether you're writing a business
application that conforms to business rules, or whether you're writing a
development/analysis tool.
As an Amazon Associate we earn from qualifying purchases.