Re: Mapping SQL Result Sets to Browsers

["Mark Allen" <scprideandms@xxxxxxxxx>]

NEVER NEVER NEVER build the SQL on the fly, all access should/must be thru
stored procedures, anytning on the fly can be hacked/modified by a
semi-smart kiddie my manuipluating the URL

On Thu, Jul 3, 2008 at 2:07 PM, Scott Klement <web400@xxxxxxxxxxxxxxxx>
wrote:

> 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.
> --
> This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.