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.
midrange.com
