Re: Mapping SQL Result Sets to Browsers

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. 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? Or generating business objects from result sets? Is it to perform set oriented updates? Are folks doing updates from result sets? Or are database updates and business methods more of a record at a time thing? I can say that in my applications, database updates are almost always one record at a time. Data validation and business rules are applied one record at a time, in most cases. I don't understand the notion or appeal of result sets and business objects. I almost always use result sets for inquiry only.

Nathan.




----- Original Message ----
From: Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Thursday, July 3, 2008 10:02:45 AM
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers

I agree that the idea of a business object is to abstract away the complexity of the database, and if the definition of a customer (order, item, whatever) requires a join or 10 then yes, that belongs in a business object.

I'm referring more to cases where this query exists solely to support this report and the complexity of the query (and even the tables involved) vary depending on the user options selected. Can it be done with business objects? Sure. Should it? Like everything else, it depends. Business objects can get _very_ chatty with the database. Of course there,s a school of thought that you should pass the information needed to create the sql into the business layer

-Walden