Object relationships - different approaches
Graeme Geldenhuys
What do you guys and girls do with object relationships? How do you
implement them. I unit test all my objects so I would like a clean
design to help the unit tests as well.
eg:
I have multiple Centre's in a database, so I have a TCentre class. For
the accounting part of our application, we have multiple tax rates
(TTaxRate class) that apply per Centre. So in the TaxRates table I have
a Centre_OID field to complete the relationship on the DB side.
Each object in my business object model as an OID of type TtiOID (I use
the tiOPF object persistence framework). Each OID is unique across the
application and database. My OID's are GUIDs.
Should I define my TTaxRate class as follows... It contains a object
reference to the Centre
Option #1:
TTaxRate = class(TtiObject)
published
property Centre: TCentre read ...
property TaxCode: string read ...
property TaxDesc: string read ...
property Rate: Currency read ...
property EffectiveDate: TDateTime ...
end;
...or something more generic like the following... It only contains the
OID of the Centre as a string. So I can still do lookups in the
CentreList to find the related centre.
Option #2:
TTaxRate = class(TtiObject)
published
property Centre_OID: string read ...
property TaxCode: string read ...
property TaxDesc: string read ...
property Rate: Currency read ...
property EffectiveDate: TDateTime ...
end;
... or no direct relationship. And have some external class keeping the
relationship. Maybe some Relationship Manager implementation.
Option #3:
TTaxRate = class(TtiObject)
published
property TaxCode: string read ...
property TaxDesc: string read ...
property Rate: Currency read ...
property EffectiveDate: TDateTime ...
end;
Option #1 is nice for the developer if you need to find the related
Centre from the TaxRate. But it's more difficult to code the unit tests,
plus you have a direct relationship to a TCentre class, so you can't
really reuse the TTaxCode in any other application.
Option #2 allows for some reuse of the TTaxCode class, because TtiOID is
generic for any tiOPF based applications (which all our applications
are). It's more work for the developer to find the related Centre from
the TaxCode, but makes unit testing a bit easier as I can fake the
Centre OID without a actual TCentre instance.
Option #3 allows a for the easiest code reuse as there is no direct
relationship to any other objects. It makes it much harder for the
developer to get the Centre from the TaxRate as I would need a external
class to manage that. This case is easy to unit test though.
How do others implement such a relationship? What is your
recommendations and the advantages/disadvantages of your choice?
Regards,
- Graeme -
_______________________________________________________
fpGUI - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/