[Minibits-general] OO, Database Migration

[Rob W. <ro...@na...>]

Carlos,
I'm very much in favour of using classes in the system.
I think that in order to implement this the best way to go would be to do
the following...
When I first went in for re-usable code I started to move some code from
forms to modules.
The most complete example of this is trnWIPADD.
Have a look at the class diagram on the project homepage, which may give you
a good overview of the potential objects ofthe system (this will be added to
over the next few days.)
Then have a look at trnWIPADD and see how it interacts with its form,
frmWIPADD (very simply).
If we were to add the other functions involving the same form to a generic
module trnWO then we may have laid ourselves a good foundation to move to a
more oo way of working. By having one works order class in trnWO to cover
adding, changing, deleting, etc., we would give ourselves great advantages I
think.
My big questions tho, are these....
We would I think gain significant benefit from moving ALL processing for a
table to a single module. But how would we then treat that processing to
gain maximum benefit??? Are you thinking, as I am, of having a class for
each table, with add, delete, change and retrieve methods??? A number of
forms use multiple tables also, so we may be better having a 3-tier system:
1) The top tier handles the GUI processing.
2) The 2nd tier handles the transactions as MiniBits functions.
3) The 3rd tier handles the class/recordset interaction.

Thus for a transaction such as INVMOV:
1) STKDTL, STKLOC, STKSIT, INVMOV generate a call to trnINVMOV in the second
tier.
2a) trnINVMOV generates a call to cStock to validate the data
3a) cStock returns appropriate data
2b) trnINVMOV generates a call to cStock to add a data item
3b) cStock returns success
2c) trnINVMOV generates a call to cStock to delete a data item as necessary
3b) cStock returns success
2d) trnINVMOV generates a call to cHistory to add a data item
3b) cHistory returns success

I would suggest this to avoid a system for compound transactions where
object calls another etc.
Any comments on my musings???


In terms of the db, that's just what we need.

Cheers
Rob

-----Original Message-----
From: Carlos Daniel Ruvalcaba Valenzuela [mailto:cls...@ya...]
Sent: 10 August 2003 17:40
To: Rob Walters
Subject: Re: [Minibits-general] MiniBits Developer Settings


Rob, i'm looking foward for a more reusable way of
doing things, like using Classes, we can create
classes to create interfaces based on the fields of a
table (this is an easy thing), and have capabilities
depending on settings. Though i'm seeing that it may
be posible to start almost from scratch.

About the database, i was considering to create a tool
to help to create the MiniBits database (on the fly),
it can be added the ability to customize the tables,
migrate data, etc.

By the way, i'm having problems with my ADSL provider,
because of this is wasn't able to comunicate sooner.

Comments, ideas, flames?
Carlos Daniel Ruvalcaba Valenzuela

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx