Use a caching Scheme for all static data on your client to aid Client Side
Lookup, Validation, and Matching ID's against Codes, Descriptions etc.. Use
CDS for this - you can make a storage class for them using TCollection
pretty easily if U want, and just figure when you need to re load from the
server - probably very infrequently if you plan it right. Because the CDS
streams Packed Byte Arrays, the traffic between Server and Client is about
the thinnest you can have anyway - far more efficient than HTML. So don't be
scared of a little more traffic.
Don't underestimate the power of what you can do with the inbuilt streaming
between TdatasetProvider and TclientDataset. You can use the Event handlers
on the CDS and Provider to great advantage also. Typically I cache 30~50
tables on the Client - most are less than 1 K of Data so the memory overhead
is low. Once you have the cache operating you have a lot of power at your
disposal. I have found that you can efficiently cache up to about 100Mb of
data in a single CDS with significant benefit, but rarely does the need
arise to cache large tables because they are usually transactional. When you
refresh, and wher you refresh from depend on the Application Archetecture.
There are no fixed rules for this. The Cache is also very useful at
reducing the number of tables in a join - so your server side SQL can run
much faster. However, try to place your BL as much as possible on the
server. View you client as a presentation layer only. I found it quite hard
to change from 2 Tier to n Tier thinking. I cache heavily at both the Client
and the Server.
There are many ways you can implement BL on the server Martin. Make use of
the Provider Before and After apply Updates, and in particular
BeforeUpdateRecord handler. You need to experiment a lot with these to
realize their potential. I replace DB Triggers, SP's, PK Generation etc with
middle tier logic now. It makes your app as impervious to Database Vendor
change as you can get. With this approach even SQL SERVER_SUX almost makes
it as a useful - if dreadfully overpriced - database - although no matter
how you look at it its still a decade behind all the other DB's.... That
should draw a few MS supporters out! Check out all the Midas sites
regularly to keep in touch. The Midess site is growing steadily with some
nice free code available. I have posted a Threaded ADO Connection pool to
Midess to assist if you are using ADO. Use Provider flags on the Persistent
Fields on both sides of the fence to control your Update Domain. Embedded
Details can be helpful in certain circumstances especially with judicious
use of the Provider BeforeUpdateRecord handler. You can also leverage MTS
and MSMQ with Midas to great advantage. Dynamic constraints are another
powerful tool. There are good papers to be found on all this stuff if you
look for them - excepting MTS and MSMQ.
On the server side, the Schema of the Provider can be quite complex. There
may be several tables involved, and perhaps some pseudo columns. I view the
Provider as a business Object. I used to think of it as just another
connectivity object. I was wrong. The provider is the Provider of data and
logic to the client. I often have exported functionality in support of the
provider as well. ... I mean Exported Stubs from the RDM which can work well
to assist your BL.
Good luck,
Tony.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Alan Rose
Sent: Thursday, 18 January 2001 5:53 p.m.
To: Multiple recipients of list database
Subject: RE: [DUG-DB]: 3 tier and business rules
Martin if you really really need to know immediately that the campaign name
typed in is unique then you have no choice but to do a lookup. (cant imagine
that been too much of an overhead anyway)
(You will still have to test this condition on Post anyway)
Middle tier is definitely the place for your business rules to get the
benefits of using a three tier system.
Having said that if your client app is always going to be a Delphi app then
doing extra validation in the client does hurt e.g forcing uppercase,
controlling entry into an edit box (old saying prevention better than cure)
etc
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Martin Ease
Sent: Thursday, January 18, 2001 2:24 PM
To: Multiple recipients of list database
Subject: [DUG-DB]: 3 tier and business rules
Hi all
Here is a question which I'd like to get some feedback on:
I first of all will admit that I am a very recent convert to the world of
multi tier. My experience so far is that Delphi makes developing 3 tier
_relatively_ easy, and I enjoy it a lot.
The issue is where to store business rules, as this is what I've heard/read
about to be one of the many benefits of multi tier development.
All business rules ideally would be stored in one common place, i.e. the
middle tier. For a MIDAS application that is the MIDAS server, right?
Now image this example:
On the client I have a screen which lists campaigns. The user can
add/modify/delete campaigns, and amongst other things each campaign must
have a unique name (business rule). If you don't agree with the fact that
this is a business rule, please imagine one that you do agree with as it is
not the central point I am making here.
Now the user wants to know immediately after making a change, or adding a
new campaign, that the name satisfies the uniqueness constraint.
Using client data sets (CDS), the change would only be posted to the MIDAS
server, once the screen is closed (or even once the whole client program
terminates). This does not satisfy the user as they want feedback
immediately.
To get around this, I can either post all changes immediately, or do a
special lookup to determine that the campaign name is unique. In either
case, I have to generate extra traffic between client and server, which is
what the whole multi tier architecture is trying to minimise.
I also know that I can add constraints (which are a form of business rules)
to the dataset on the server, and migrate these to the client via the
provider interface. However, some business rules cannot be expressed as
record level constraints, so what do you do?
I'd be interested in any feedback, suggestions etc.
Cheers
Martin
"WS SMTP relay" made the following
annotations on 01/18/01 14:23:56
----------------------------------------------------------------------------
--
[INFO] -- Content Manager:
[MMSSOV] This e-mail message and any attachments are confidential to
Sovereign Limited and subsidiaries and subject to legal privilege. If you
have received this e-mail in error, please advise the sender immediately and
destroy the message and any attachments. If you are not the intended
recipient you are notified that any use, distribution, amendment, copying or
any action taken or omitted to be taken in reliance of this message or
attachments is prohibited.
============================================================================
==
---------------------------------------------------------------------------
New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Database List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
