Re: Long Life Objects


<snip>
Therefore my current design simply instantiates an instance of
AddressType with data from the RDB and that instance is held as an
attribute of an Address instance. This approach is substituting sub-
typing for a reliance on the unique ID AddressTypeID so that tests for
an address type must check the int based ID against an application
constant. For example, in the billing area I would need something
like:
const int BillingAddress = 3;
if (Address.AddressType.AddressTypeID == BillingAddress )

This seems messy but I cannot find a way to handle such application
'type' objects that are not known at design time. How do you deal with
this sort of situation?

OK...this isn't the end of the world....but I know what you mean.

Some of the decision comes down to what sort of datahandling
environment you are
i.e. if you live in MS typed dataset world, the pain of mapping typed
records to arrays of domain objects is generally not worth it, because
all the MS infrastructure, grids etc, work out of the box with
datasets and don't really work (or are very painful), when presenting
data in other forms.

If you do want to map to domain objects then the fact that users can
create composite objects based on some template shouldn't really stop
you.......you may need some code that looks like the above (though
there are more ways to do it...see try Fowlers enterprise architecture
patterns)....but only in some sort of record factory object....it
looks at the typeid and then instantiates the corresponding object.

.