>> 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" <email@example.com> 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.
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL