Re: You have my sympathies

On Wed, 15 Mar 2000 21:56:31 -0000, "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:

>Minor details aside - let's review this paragraph:

Yes, that's taken care of appropriately now.

>
>>Any application enforced constraint must be
>>enforced by every app that touches the data.
>>Much duplication.
>
>In a correct 3-tier design there is arguably
>only ONE application EVER that touches
>the database, and that is the business
>rule engine in the application server.
>

There is no such thing as a correct 3-tier design. Not more than there is a correct C/S design or any other design. All designs have flaws, because they are made by humans and the systems being modelled are too complex for a single human to grasp.

Also, I think that your "arguable" is very arguable. There is nothing in 3-tier technology that says there should only be ONE application. That is extremely limiting. A few more arguments against follow:

Traditional systems (before C/S) where very code heavy and tending to get worse. Hence the need to partition the design rules. Rules that relate to data integrity should be where the data is. Rules that relate to business operations (how to apply a discount, etc...) should be at the business layer.

<more to follow>

>Moving on to the other point you make:
>
>>The database does NOT duplicate the code 'built
>>in to the business layer'. The 'business layer'
>>should not duplicate constraints taken care of
>>by the database.
>
>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. (For advocates of the "Fast net connection, we don't need to bother" school:

GET REAL!
).

>Is the business layer simply supposed to fire the
>order at the database and then cope with whatever
>error message the database returns ?

Exactly. Besides a lot of other things. Like deciding what to do next with that error.

>Wouldn't
>that lead to a very thin business layer ?

Not at all. The number of business rules that can't be controlled at the pure data level is very large (again, in an ideal "business layer" design).

> At which point
>you might ask why bother with it ?

Because pure C/S is not feasible with current application maintenance and distribution technology. Hence the need for the thin client and the 3-tier model.

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.

The 3-tier model is not a replacement for database technology, it's a facilitator of the C/S model. The fundamental properties of the C/S model in isolating business rules into the client and data rules into the server do not need to be ignored by the 3-tier model. In fact, doing so is getting into the darn territory that C/S was supposed to free us from in the first place.

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Thu Mar 16 2000 - 00:00:00 CST