On Fri, 15 May 2009 09:00:26 -0700 (PDT), jostein.solstad@xxxxxx
>I'm still not sute I get this. Or maybe I have described my situation
>in a wrong way. I'll explain a bit more in detail.
>The Member class is not a typical member/role situation. Here, a
>Member is like a Member of a club. Like it has a valid from and valid
>to date, membership number etc.
>The Customer is a regular Customer in an online shop on the web page.
>You do not have to be a Member to be a Customer and you do not have to
>be a Customer to be a Member.
I assume a Member can also be a Customer. To me this suggests two
roles, Member and Customer. This would allow an entity to have a
membership in either or both roles. Depending upon what you're trying
to do, an alternative might be making the Member a Customer by
default. I'm thinking a Member can be a Customer who hasn't made a
>So far I created the Person class to have person specific data, like
>firstname, lastname, birth date etc. All the data in the Person class
>is valid for both a Customer and a Member, that's why I wanted a
>Person class to handle this. Now, the problem is that a customer can
>also be a company. The company does not have first name, last name,
>birt date etc.
So what you're really saying is the Person class is not suitable for
all Customers i.e. Customers that are companies.
>So how do I create the structure so that it should
>handle both Person and Company as a Customer. Mind, in a list of
>Customers, I need to be able to represent them both..
If I understand the scenario correctly an entity can be both a
Customer and a Member. Now if a Customer is a company then a company
can also be a Member. This means the Person class is not suitable for
all Members either i.e. Members that are companies. The initial
concept of Members and Customers always being of type Person is where
the problem originates. Let's look at it differently.
The big commonality between individuals and companies using the
front-end is they have to somehow register to be a Member, a Customer
or both. When an entity registers, an account is opened. This can be
represented by an Account type.
Members of the Account type would include the Role(s) along with an
AccountName. The AccountName property doesn't have to be tied to the
name of an individual or company, it is just a way to identify the
Since the account can be used to buy stuff BillingAddress and
ShippingAddress members will also be needed. The account will also
need to include contact information. This would be either the
individual represented by the account or the individual selected by
the company represented by the account. The Account type can be
fleshed out to include whatever other information is pertinent to the
I realize this may not be the solution you desire but you do need to
back away from the design flaw where everything is exclusively based
upon the Person type.