|
|
Today I answer in Delphi-DB mailing list about subj. I
remember, that few weeks ago we too wanted to discuss this theme.
Also I decided to post this message here too. Let it will be by
today's delphi tip.
********************************************
On server database I have a few own "system" tables
with descriptions of project:
1. CLASS table is a list of all available user queries with short
description, select/update/insert/delete statements
2. DESCRIPTION table stores the descriptions of fields for each
record in CLASS
3. a few additional tables with security (user, groups,
privileges, access modes etc)
PS I do not describe them, as for the basic description they are
not so important
In application I have a main datamodule, which contains the one
TDatabase component (linked to my alias).
Also I have a some TDataModule component which are the parent for
each other. On this component I dropped the TQuery (linked to
main TDataBase), and TUpdateSQL and TDataSource, which are linked
to TQuery.
Also in this parent datamodule I included the some additional
properties and procedures/functions:
1. to get a descriptions from server by class name
2. to fill a update/delete/insert properties of TUpdateSQL
3. to change a filter (via where clause), a data order (via order
by) etc (any clause in sql - I use a some macros in own sqls)
4. save/cancel changes, refresh data
5. to get the new ID (for autoincremental fields)
6. to read a user privileges
7. to open class
8. to get a "lookup" class
PS: I not use a delphi lookup fields. Instead it I store in class
descriptions for some fields the additional info (which class I
must open for edit/view of data, which fields are linked in
"lookup" class etc and more)
9. and more additional features
Each datamodule are successor of this parent DM with
"personal" extension in business logic. For example, in
the class for details of orders I defined the specific
calculations (some subtotals and sums) or procedures (check of
outputing qnt). The full logic I included in these DMs only (in
visual forms I use a calls only!).
Also I have a basic visual TForm with grid, navigator, filter
panel etc.
This form have a "linked" DataModule. Also this form
known how:
1. to fill the info from DM (a columns list for dbgrid (from
description in DM), form caption and more)
2. to call a form for edit/append of record (those form not uses
the any DB-components!!)
3. to generate report (I use a SMReport)
4. to export data (I use a SMExport)
5. to find a record by some criteria
6. to select a records (the some forms I use for selecting of
some recors)
PS: for example, in orders mode my users can select a records
from product class and append the wished
7. to open a "lookup" class
PS: for example, in grid with customer list my users can open a
class of customer types (instead standard delphi lookup field) or
"drill" in orders list for this customer
8. to setup the visualization of data (fonts, colors, order etc,
filter, sort and grouping)
9. and more additional features
All the rest forms are successors of this parent and are
different one from other in needed possibilities only. For
example, if my users want to calculate a sum of some order for
specific product type only, of course, I add a calc function in
linked DM and drop a button on form for calling of this function
in DM
PS: in visual forms (when I need to calc or to do a something) I
call the "assigned" method in "assigned" DM.
Also I have a two list - opened DMs and created forms. So if I
need open a "lookup" class, I search it in list of DM
and create only if I not found. And with forms I work similar.
PS: this technology I uses in tens projects (current and
finished), in small app and in big projects. I described the
customers-orders-products schema for availability of
understanding only. Of course, sometimes (more often in the
beginning of development of small app) the perspective of the
extension of functionality up to large client-server system (and
especially multi-tier) is not visible and it's possible to go on
easy way - drop on form the ttables (or even to allocate them in
separate datamodule), linked it with grids, use a master-detail
link and lookup fields etc
But when you decide to expand possibilities of the app and
transfer it from local DB (Paradox/DBase/Access etc) on normal DB
server and maybe use a 3-tier you will understand, that is
necessary to change the approach to DB programming for rise of
productivity, easy support and extension of project.
Of course, it's my opinion only, but I have come to such
technology by many cuts and tries during 10 years on different
DBs and tools of development. Though I still do not have also
thirty years I have a large number of successful developments in
other departs and if I can to someone reduce this long way, it
will be well.
I do not apply for indisputable true and I know many weak places
in the described technology, but they not impasses - it is simply
not up to the end are realized (and it's good:)))
I shall read criticism of other with pleasure too.
PSS: I'm sorry for long message. I shall be in vacation for
Monday (from 6 to 20 September) and if someone will want to ask
me (or simply to write a message), send it not only in list but
duplicate it on my e-mail too, please. I shall be on work today
and tomorrow only, but after vacation I shall answer all messages
(if I not answer before vacation shall have time).
********************************************
Published: September 2, 1999
|
|
Home
