Design av t ex Customer

Hej! En design fråga:

Låt oss säga att jag har en klass Customer. Förutom vanliga properties som FirstName och LastName behöver jag en Property CustomerType eller kanske CustomerTypeID?

Det finns fn 5 olika kundtyper. I databasen kommer dessa representeras av att det i Customertabellen finns en foreign key CustomerTypeID.
Customer:
CustomerID (räknare)
FirstName varchar
LastName varchar
CustomerTypeID int (foreign key)

Jag har också en tabell

CustomerType:
CustomerTypeID (räknare)
CustomerTypeName (varchar(50)) Ex: Privat, Företag, Offentlig.

Frågan är då om Customer bör ha en property CustomerTypeID (integer) eller propertyn CustomerType (string) (lagra t ex Privat)?

Då man ska presentera ett customer-objekt i GUI så är ju det praktiskt med en sträng och CustomerType, men vid uppdatering av Customer objektet så verkar det ju enklare med CustomerTypeID (int).

Vad är best practise här?

Antingen så tycker jag att du skall ha ett objekt för varje CustomerTyp som ärver av en abstract Customer, eller så tycker jag att du skall skapa ett object för varje Customer typ som innehåller beskrivningen av vilken typ Customer är.

Nickemannen skrev:

Antingen så tycker jag att du skall ha ett objekt för varje CustomerTyp som ärver av en abstract Customer, eller så tycker jag att du skall skapa ett object för varje Customer typ som innehåller beskrivningen av vilken typ Customer är.

Hmm, ditt andra alternativ låter väl bäst om vi antar att det tillkommer fler kundtyper. Det kräver mindre underhåll än ditt första alternativ.