>> I have never seen a beautifully implemented Business Rules Layer which
>> sat on top od the Business Objects Layer. I don't really think it
>> can be done.
I hate to expose myself as a fraud after my initial comments went down so
well, but I would be grateful if you could explain what the difference is
between a business rules layer and a business objects layer?
As for SPs, I don't see a problem with implementing numerous similar SPs
in the DB: e.g:
Putting in 3 different SP names to your app makes the middle tier code far
leaner than putting in SQL code (plus you get performance/maintainence advantages
As for the interface definition of the objects used to execute these SPs,
you can have a generic 'Execute' method that determines which SP to call
based on which attributes of the object have been populated. For example,
imagine the following class:
Execute() has no parameters. Its implementation is such that if region_id
is Null and cost_centre_id is Null, then call get_employees, and so on and
Re: Please elaborate
"Adriano" <firstname.lastname@example.org> wrote:
>I hate to expose myself as a fraud after my initial comments went down so
>well, but I would be grateful if you could explain what the difference is
>between a business rules layer and a business objects layer?
Oh! I expose myself as a fraud all the time. It's very liberating.
Stops people taking you too seriously.
On the distinction between business objects and business rules.
I "think" a commonly accepted definition of a business rule would
"A constraint on the relationship between objects and or between
properties of an object"
In english, (slightly contrived) if you have a collection of bank account
objects associated with a customer, there may me a business rule that
states that a customers overall balance must remain positive.
This would allow you to have a negative balance in some accounts as long
as the balance in the other accounts was sufficient to give an overall
This is actually a pretty crap example, off the top of my head.
>As for SPs, I don't see a problem with implementing numerous similar SPs
>in the DB: e.g:
>Putting in 3 different SP names to your app makes the middle tier code far
>leaner than putting in SQL code (plus you get performance/maintainence advantages
Yeah, it's pretty common, a lot of people like it. I like to be able to
write the code once, and no matter what bizarre query the user comes
up with I can do it. I can query in terms of the obejcts and the properties
rather than the underlying tables and fields.
So, you want all employees who earn between $30,000 and $50,000 and who
work in Region 1. OK, you got it. I don't need to write a stored proc.
That's the only reason.
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center