Re: You have my sympathies

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: 2000/03/18
Message-ID: <953420482.7091.0.nnrp-08.9e984b29@news.demon.co.uk>

Nuno,

Thanks for the various replies - plenty of good points made there; though I had to print it all out to think about it.

The direction I was coming from was a reconsideration of what may or may not have changed as the technology changes.

I liked especially your reminder

"Let's not forget that the fundamental reason for the emergence of the"
"3-tier model was the problem of maintenance of the fat client. And"
"rightly so. Not the logical shortcomings of the C/S model, the"
"physical ones."

and the good pragmatist's viewpoint:

"The problem is separating the rules into what is data"
"integrity rule and what is a functional rule. "
"Spread the rules into the layer that executes them better and safer"
"and you got the perfect solution."

though I think that having done this most of my rules (both types) would be in the database, but I would call several of them one at a time, which I think might be a little at odds with your approach

I was interested in the fact that the example you gave of a business rule was 'output oriented' though. (A customer writhe no orders should receive heaps of advertising -- this is a report, not an interaction between an end-user and the system, and my thinking is biased towards the fact that Client/Server and 3-tier are about the input/validation stage rather than the report stage). Would anyone care to come up with some examples of 'business rules' or 'business layer functionality' that can't be best implemented in the (Oracle) database ?

What kicked off my contribution to this thread was the (possibly contradictory) thoughts that

3-tier is somehow supposed to split the application into

        presentation layer
        business layer
        database layer

I haven't yet come across code in the business layer that couldn't be done better by being in the (specifically Oracle) database as integrity constraints, triggers, or calls to packaged procedures

Most 3rd party applications using the 3-tier model use lowest-common-denominator approaches so that they can talk to 'any relational database' (including flat files !)

The world is going wild with CORBA and Javabeans where you buy a handful of business-driven code components from different people, string them together and have an application.

End-users tend to prefer drop-down lists and instant validation to filling in a form and being told 10 seconds after they have finished it that the second field is wrong, and the necessary implementation leads to fat-clients, a small but very cunning engine permanently installed on the client, and in either case this seems to demand lots of network turn-arounds - and possibly a very clever, very hard working business layer.

Is there a newer, least-worst, way of using emergent technologies to address the conflicting requirements of

    happy users
    optimal performance
    minimal code maintenance

My comment about there being only a single application that touches the database refers to the concept that you have the order 'javabean / business object / whatever' and any 'end-user' application addresses only That Thing in a limited set of ways, and only That Thing addresses the database. In my own world-view, That Thing is actually an Oracle packaged procedure, of course - (except for the special 'bulk-loading' option where one row at a time is never good enough ... and there goes the purity of the system ;)

Following up this bit of the dialogue

    >Does this mean that when the presentation layer
    >sends in an 'order' the business layer should not
    >check that the order is for an existing customer ?

Exactly. If the database has that rule installed, there is no point in doing the extra check at application level: it loads the "wire" between the application processor and the database and it is an operation that can be done most efficiently INSIDE the database.

Does this mean that you send the order to the database and get a list of all the errors returned, which you then forward to the client ? Sounds like a nasty piece of code in the business layer. Even if you do it the easy way - send the package, get just one error message you then have to:

ensure that the business layer and database layer know the list of legal error messages

get the business layer to run through its list along the lines of:

        case return code is
        XXX )          do action 1
        YYY)           do action 2
        end case

Putting the 'data integrity' rules into the database doesn't really remove any duplication in the code, it just camouflages one copy - if I introduce a new business rule 'order must be over 20 pounds' and check it in the database (because it is data integrity and I can) then I have to 'copy' the check into the business code layer, albeit disguised as: 'if error 99 is returned by the database push a message to the presentation layer that the order is too small'.

I also think that your example of John Doe with the five orders being a 'proof' that the database ought to handle the data integrity is slightly suspect. In the hands of the appropriate coder the orders could still end up belonging to someone else - database integrity ensures only that they end up belonging to someone. (Of course this is important, and it is a valid feature with Oracle specifically which does not allow a 'shareable read lock' that the database does handle the integrity otherwise the application could check that John Doe exists and insert the orders, and find that John Doe has disappeared in the interim - but this is a case where available technology confuses the issue between an ideal and
what will work.)

BTW - what does <d&r> represent ?

--

Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

Nuno Souto wrote in message <38d0a855.4414572_at_news-server>...
>
>Careful. I don't think Jonathan is unaware of these issues. As he
>mentioned, he's playing devil's advocate. IOW, he's trying to think
>like someone who doesn't know the importance of these things. So that
>he can crystalize his thoughts.  Nothing wrong with that. Or else he's
>trying to "fish" for how much we know about the subject. Nothing wrong
>with that either.
>

Received on Sat Mar 18 2000 - 00:00:00 CST