ricker
asked on
Can OOP use TDBControls?
Hello Experts:
I am fairly new to (real) OOD and OOP. My background has been mostly Clipper projects (yeah, yeah, we all know Clipper is passe). Nonetheless, I used all the power in Clipper (code blocks etc) to write code which was somewhat object oriented. The apps I write are mid size multi-user financial, sales entry, inventory control and reporting systems for vertical markets. To give an idea of size, some of our clients achieve 1,000,000 plus GL transaction records in a two year span.
I've gained a fairly good grasp of Delphi (2.0) but now I have an OOP question.
In the past, I would never think of placing database fields into a user interface, as the DBControls in Delphi suggest... i.e. To edit a customer, I would assign database fields to memory variables, then exchange upon an explicit post. With Delphi, it seems one would place the TDBEdits (or the like), directly attached to database fields, onto the editing form, and then use the events from an implicit or explicit post to check validity. This however, seems to skate away from OOP.
To wit, if you create a TCustomer class (which descends from a TAccount class), you would want the TAccount methods to take care of main account data, and TCustomer to handle customer specific attributes and tasks. This implies that the form on which a customer gets edited should retrieve field values from a TCustomer object, using TCustomer AND TAccount methods, and likewise post back changes.
Using DBControls, however, seems to bypass such a object based hierarchy, unless I am missing something. Hence my question.
To maintain an Object Oriented Design, should I be using DBControls for editing objects such as Customers? If so, would this preclude the use of a TCustomer class while editing the account? Alternatively, am I better using TEdits, where the form retrieves initial TEdit values from a TCustomer object, which in turn handles all data access, validity, etc.
I have given this question 100 points. If a truly comprehensive response is in order (as I expect), I will raise the points so I might learn, through your wisdom, the correct methodology.
Thanks in advance.
I am fairly new to (real) OOD and OOP. My background has been mostly Clipper projects (yeah, yeah, we all know Clipper is passe). Nonetheless, I used all the power in Clipper (code blocks etc) to write code which was somewhat object oriented. The apps I write are mid size multi-user financial, sales entry, inventory control and reporting systems for vertical markets. To give an idea of size, some of our clients achieve 1,000,000 plus GL transaction records in a two year span.
I've gained a fairly good grasp of Delphi (2.0) but now I have an OOP question.
In the past, I would never think of placing database fields into a user interface, as the DBControls in Delphi suggest... i.e. To edit a customer, I would assign database fields to memory variables, then exchange upon an explicit post. With Delphi, it seems one would place the TDBEdits (or the like), directly attached to database fields, onto the editing form, and then use the events from an implicit or explicit post to check validity. This however, seems to skate away from OOP.
To wit, if you create a TCustomer class (which descends from a TAccount class), you would want the TAccount methods to take care of main account data, and TCustomer to handle customer specific attributes and tasks. This implies that the form on which a customer gets edited should retrieve field values from a TCustomer object, using TCustomer AND TAccount methods, and likewise post back changes.
Using DBControls, however, seems to bypass such a object based hierarchy, unless I am missing something. Hence my question.
To maintain an Object Oriented Design, should I be using DBControls for editing objects such as Customers? If so, would this preclude the use of a TCustomer class while editing the account? Alternatively, am I better using TEdits, where the form retrieves initial TEdit values from a TCustomer object, which in turn handles all data access, validity, etc.
I have given this question 100 points. If a truly comprehensive response is in order (as I expect), I will raise the points so I might learn, through your wisdom, the correct methodology.
Thanks in advance.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you´re making "small" programs or using prototyping, the DB controls are very easy and fast to use.
They fits perfectly with the RAPID application development concept of Delphi.
BUT, if you developing a big (>30-50000 lines of code) application, you WILL run into some MAJOR problems along the way.
It will be very difficult to correct errors, re-use code or make a good object oriented program. It´s also very complicated to make team development, if you´re using DB controls or visual design (DFM files).
It´s my experience that visual design (drag and drop) is good for prototyping or very small programs, but if you serious about your program you have to use "hand-coding". It will benefit you in the long run.
They fits perfectly with the RAPID application development concept of Delphi.
BUT, if you developing a big (>30-50000 lines of code) application, you WILL run into some MAJOR problems along the way.
It will be very difficult to correct errors, re-use code or make a good object oriented program. It´s also very complicated to make team development, if you´re using DB controls or visual design (DFM files).
It´s my experience that visual design (drag and drop) is good for prototyping or very small programs, but if you serious about your program you have to use "hand-coding". It will benefit you in the long run.
ASKER
Thanks for your comments miv....
It still disturbs me, now that I have invested so much time in learning Delhi, that it appears all the RAPID tools are really no good for REAL development.
And that being the case, I don't know why I just shouldn't be switching to C++.
It still disturbs me, now that I have invested so much time in learning Delhi, that it appears all the RAPID tools are really no good for REAL development.
And that being the case, I don't know why I just shouldn't be switching to C++.
ASKER