How should Lookup Values be represented in ASP.NET Business Objects?

I'm currently writing an N-Tier architected ASP.NET system with a relatively normalised SQL data开发者_JS百科base backend, but I'm struggling to get my head around how lookup values should be represented in my business objects (I don't get the priviledge of using EF or ORMs). My table (as an example) could be structured like this:

CoreDataTable:

ID | Name  | Favourite_Colour
---|-------|-----------------
01 | Peter | 01
02 | John  | 03
03 | Mary  | 05

ColoursLookup:

ID | Colour | is_active
---|--------|----------
01 | Red    | 1
02 | Green  | 1
03 | Blue   | 1
04 | Pink   | 1
05 | Black  | 1

Now initially, I had created my business object to look like this:

public class Person
{
    protected int PersonID { get; set; }
    public string Name { get; set; }
    public int FavouriteColour { get; set; }
}

But what should I do when, for example, I want to list all the people in the database, along with their favourite colour? I can't show just the lookup ID, so at the minute I see 4 options:

1. Add a method to the class called Person.GetColourStringValue that gets the colour name from the database when called. This would be inefficient since using this method on 100 "Person" objects would result in 100 database queries.
2. Have the FavouriteColour property of the Person object as a string, and do a reverse lookup whenever writing a person object to the database (i.e. take the colour name, and get the corresponding ID). This is dangerous IMO in the unlikely circumstance that two colours have the same name in the database.
3. Store both the ID and the value in the Person object, and synchronise them whenever one or the other value is updating. This seems overly complex for a relatively trivial task.
4. Create two representations, the Person object, and a PersonSummary object which pulls back a read-only version of the object, with all lookup values converted into their descriptive names.

I'm 100% convinced that I'm (a) overthinking this, and (b) making it more complicated than it needs to be. So, is there a preferred way of doing this? Or is there an option that I've overlooked? Any help is appreciated, I've been tackling this for hours now without coming to a decision.

Thanks.

---

The only proper way to answer this is to choose one, measure the impact (through a prototype if necessary), then compare that to the impact of the next option.

Without knowing your system, I would say that option 1 is likely to be the best -- IF you were to cache a series of Color objects so you didn't need to head to the database each time.

---

How about having a join to the colour table in the query that populates the person table. Have a FavouriteColor property on the person object. The object will not be a true representation of the table columns, but all of the info needed will be retrieved in on db call.