Parent Child Relationships with Fluent NHibernate?

I would like to create a cascading tree/list of N number of children for a given parent, where a child can also become a parent.

Given the following data structure:

CountryType=1; ColorType=3; StateType=5

6,7,8 = {Can, US, Mex}

10, 11, 12 = {Red, White, Blue}

20,21,22= {California, Florida, Alberta}

TreeID  ListTypeID  ParentTreeID           ListItemID   
1            1       Null                   6   (Canada is a Country)
2            1       Null                   7   (US is a Country)
3            1       Null                   8   (Mexico is a Country)
4            3       3                      10  (Mexico has Red)
5            3       3                      11  (Mexico has White)
6            5       1                      22  (Alberta is in Canada)
7     开发者_运维问答       5       7                      20  (California is in US)
8            5       7                      21  (Florida is in US)
9            3       6                     10  (Alberta is Red)
10           3       6                    12  (Alberta is Blue)
11          3       2                      10  (US is Red)
12          3       2                      11  (Us is Blue)

How would this be represented in Fluent NHibernate classes?

Some direction would be appreciated.

Thanks.

---

If this model doesn't get any complicated than this I would go for a simple TreeNode entity with a NodeType enum property, a Name property and a ParentNode property of type TreeNode.

If you plan do add some more complexity to the different node types I would go for a TreeNode entity subclassed to different node types by a NodeType discriminator.

---

Tree solution is good, however in this case, a detached-type data model will work best.

For example, I have a given list. I then want to associate each item of that list with multiple items - which could even be another list.

Thus, I a type called LinkedListItems - which are essentially items, only that they contain one additional piece of information - a ParentID field.

This works better than a tree type of data model because I can now associate a secondary list item with multiple primary list items, whereas a tree model would represent a 1..* relationship.