Recent

Author Topic: best practices: how to store objects in tables  (Read 2063 times)

garydale

  • New Member
  • *
  • Posts: 17
best practices: how to store objects in tables
« on: July 28, 2011, 10:07:26 pm »
Looking for guidance here on the best way to handle persistent objects. In my particular case, I have lists of various types of objects with very little polymorphism (they all contain the same fields within a class).

An example would be an address. You need street #, apt #, street name, etc.. Let's also say that you can give each object a unique id so they can be loaded and stored using that id.

Is it better to expose the list as a separate object (of whatever database class I'm using) or to hide it within the address object (using, for example, load and store methods for individual addresses)? Or is there another way of doing this?

Obviously, the simplest is to use a separate object of some database type, open it when the form is created and close it when the form is destroyed. However that exposes the database everywhere that data needs to be loaded or set. The database is essentially a globally visible object.

Hiding it within an address object seems cleaner but then there would be database instances for each address object. The workaround would again be to make the address object globally visible.

I used to get around this back in the dBASE for Windows 5.0 days when a class could have startup code. However, Visual dBASE 5.5 removed that capability.

Object Pascal also has similar capabilities in its UNITs - carried over from the UCSD Pascal days, I believe. How do people feel about putting persistent objects into separate units and hiding the underlying database that way?