Re: Where do business rules belong... OCP and SPs

From: JXStern (JXSternChangeX2R_at_gte.net)
Date: 01/20/04 

Date: Tue, 20 Jan 2004 01:48:07 GMT

On 18 Jan 2004 20:38:36 -0800, bentalcy@yahoo.com (Yaron Bental)
wrote:
>Being an OO follower I believe, and I know a few other do too,
>business rules belong in the business tier, we all know the reasons.

No, I don't know the reasons. I've never heard anyone offer any
reason except that they want to write in language X, which they can't
do at the database tier. Who says it makes any kind of sense at all
to even have a business tier? It was simply assumed into existence
about six years ago, because object technology was too fat and slow to
share a 100mhz server machine with a fat, slow database engine, and
the web tier had to have simple expandability so objects couldn't live
there either. There never was any real logical reason, it was only a
collection of hardware reasons.

>With that habit in mind and in practice I set some time this week to
>improve performance on a very slow page in one of the apps my team is
>responsible for. I knew I have to touch a set of stored procedures and
>in my mind I thought I wanted to move all the business rules captured
>in the stored procedures back to where I think they belong.

Easy -- just duplicate all the database raw tables onto your business
tier, and grind away. So, what's the problem? :)

>No meter how hard I tried I could not move those rules into the middle
>tier, performance would just degrade. Some of the stored procedures
>filter (using some very complex business rules) through hundreds of
>thousands of records. Simply moving this data into some classes and
>filtering/calculating it there, just doesn't make sense, from
>performance point of view.

It's simple math, just figure how much data you have to move, assign
any reasonable metric to execution speeds, and see what the most
efficient design is.

Now, just what these complex business rules really consisted of, is
the question. I see Alfredo Novoa has already made the point that
many of these "rules" can be done declaratively, at virtually zero
cost. That's what makes a data model important, as well as efficient.

What you want to do is realize that data model in the middle tier, and
it should also be realized in the database tier. It makes little
sense to ignore it in either tier, even though it seems redundant to
realize it twice. Just because the implementation may become trivial
in the middle tier when the database tier does the work, is not an
argument against doing it!

As newer database products let you write logic for the database tier
in more respectable OO languages, these issues will be even more
important -- and architectural choices wider, too.

>Just to clarify one thing, most time I try to "live my life" without
>breaking OCP (or SRP, LSP and the other important OO principals for
>that matter) and it paid off a few time before. Obviously when you
>code all this complex business rules in the a stored procedure at some
>point or another, you either break OnceAndOnlyOnce or you might find
>yourself using too much conditional logic.

Piffle. All these things are tools, not rules.

>I suspect that this piece of code is going to be extended in the
>future. Those SPs will need to be revisited again, and code would need
>to be added with some ugly and repeated "if else" statement.
>
>Any thoughts would be greatly appreciated

Version your app.

J.

Relevant Pages

  • Re: Where do business rules belong... OCP and SPs
    ... >>business rules belong in the business tier, we all know the reasons. ... If you can't do something with data in the database tier then you ...
    (comp.object)
  • Re: Where do business rules belong... OCP and SPs
    ... the applicant name and co-signer's name should be different. ... applicant is assigned to a loans officer and a loans officer manages a ... These are non-deterministic business rules, ... the business tier or perhaps in the presentation tier? ...
    (comp.object)
  • Re: Business rules in stored procs.
    ... > that no business rules should be described by TSQL. ... > rules belong in the middle tier. ... the business rules in the same technology and tier. ... and that stored procedures just tie your ...
    (microsoft.public.sqlserver.programming)
  • Re: Where do business rules belong... OCP and SPs
    ... >>business rules belong in the business tier, ... >>in the stored procedures back to where I think they belong. ...
    (comp.object)
  • Re: Where do business rules belong... OCP and SPs
    ... >business rules belong in the business tier, ... >in the stored procedures back to where I think they belong. ...
    (comp.object)