Please elaborate


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Please elaborate

  1. #1
    Adriano Guest

    Please elaborate


    >> 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:
    get_employees
    get_employees_by_region
    get_employees_by_cost_centre etc.
    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
    of SPs).

    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:

    EmployeeData
    ------------
    employee_id
    region_id
    cost_centre_id
    ------------
    execute()

    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
    so forth.

  2. #2
    Richard Dalton . Guest

    Re: Please elaborate


    "Adriano" <adrian_osullivan@hotmail.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
    be:

    "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
    positive figure.

    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:
    >get_employees
    >get_employees_by_region
    >get_employees_by_cost_centre etc.
    >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.

    -Richard


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center