Hi everyone,
Im Looking to implement a multi addresses feature on a Root Object Called Customer.
For Example:
Customer: John Doe
Addresses:
* Business Address: 123 Test Ave
* Home Address: 456 Test St
* Other: 789 Test Blvd
Im thinking about using a child collection, but since they are predefined (Business-Home-Other) would make more sense to use a hashtable instead with a parameterized property in the Root Object?
Any Comments?
Thanks in Advance!
We've run into this scenario a number of times. What we've done is first look at an address as a free-standing object: Address. We can have a collection of these objects: AddressCollection. This collection will return a list of all the addresses in the system (keep that in mind) and directly correlate to the underlying data store.
What you are looking for is the relationship that is established between a customer and one or more of these addresses. This relationship is established by a CustomerAddress object. This object maintains the reference to the parent Customer object as well as the information contained in the standard Address object. In addition to the basic information, we typically have an AddressType property based on an enumeration, as suggested above. We have not run into the "snowbird" issue before but I am making note of it because that is certainly something we should account for. To do so, we would simply, again, as suggested above, add StartDate and EndDate properties to the CustomerAddress class as these further define the relationship, not the address iteself.
The list of addresses that belong to a particular customer is encapsulated in the CustomerAddressCollection which uses the reference to the parent Customer object to filter the select query to return only the appropriate objects.
To accomplish this, our data store is setup with a Customers table, an Addresses table and a CustomerAddresses table. The latter has fields for the Customer's ID, the Address ID, the AddressType (and our new StartDate and EndDate fields). The select query performs a join with the Addresses table via the Address ID column and returns the merged records.
The beauty of this approach is that it also supports a many-to-many relationship between Customers and Addresses with each relationship tailored to the individual combination as one person may call an address A 'home' while another calls it 'vacation home' or something.
Hope that helps.
btw - we do the same thing with phone numbers.
In the various industries that I've done work in, there have been two main definitions of addresses:
An electric or water utility has the need for the second definition, because they have a physical utility connection at an address. Customers come and they go, but the sewer pipe remains.
Most businesses only need option 1, because they couldn't care less about an address a customer used to be at, or an address a customer isn't at now.
Do you have to deal with snowbirds?
(That's a mailing list industry term for people who consistently have different addresses for different parts of the year, originally derived from all the retired Yankees from the cold northern states who live in Florida for the winter months each year.)
That's a possible business requirement that might affect your object design...
Yup, we have snowbirds ... i was thinking about that too, i guess it should be handled as another address (business-Home-Other-Snowbird) + a start date and end date.
kdlc:
Yup, we have snowbirds ... i was thinking about that too, i guess it should be handled as another address (business-Home-Other-Snowbird) + a start date and end date.
You may want to make it a start "day of month, year unspecified" or "month, year unspecified" for those snowbirds to save a lot of data entry each year.
We use a similar system
Customer > AddressList > Address.
However, The customer also has fields of PrimaryBillingAddress, PrimaryShippingAddress, and PrimaryServiceAddress. These fields simply hold an ID that links them to a specific address in the customer's address list. This made it much easier than denoting what type of address each was, specifically because most customers have the same address for all 3.
An address is something and has behavior. It knows it's type and anything else it may need.
I haven't found a need, yet, for extending the base address class.
Other objects (People, Students, Instructors, Sites) has zero or more addresses and imposes limits (if any) on the addresses it can have.
I don't feel that an address should know anything about when it is active or how it is used.
So for a snowbird it would have a list of addresses and it would know when each one was valid.
Most objects, however, simply have a list of addresses. And each address can be shared by any number of objects.
The data tables end up being StudentAddress_Link (studentid, addressid), SiteAdress_Link (SiteID, AddressID).
Now since students can have addresses defined by time (with one parent from x to y with other parent from a to b much like a snowbird) I have another object called StudentAddressSchedule. They still have zero or more addresses in a list but StudentAddressSchedule will say when an address is active for this student. The table is simply StudentID, AddressID, FromDate, ToDate. I like this approach better because the basic pattern (objects have lists of addresses) can be extended by adding an object that extends behavior.
Most of my tables end up looking like this since I always try to define the object first then design the tables to accommodate them. It drives some DBA's absolutely crazy since I have made the RDBMS into a pointer matrix. But I don't care.
Copyright (c) Marimer LLC