Re: 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.