Question

I have an Object CaseNote which has numerous child object’s like CaseNoteContactType. For 1 CaseNote there can be x CaseNoteContactType’s. In the UI ContactTypes are shown in a CheckListBox.

My question is how do I represent the ContactType child object? It is a simple int|string pair.

public Class CaseNote
{
  public Guid CaseNoteID { get; set; }
  ...
  public ??? ContactType { get; set; }
  etc...
// Down here would be Methods for saving, loading, validating, etc...
}

Would ContactType be a Dictionary? IEnumerable<ContactType>? An array, collection, or List<ContactType>??

What makes sense in these scenarios? A ContactType cannot exist with out a CaseNote but is it enough to make it an Object? I don’t understand the implications of each type. Also, does it matter that a CaseNote can have 0 to 30 ContactTypes?

Say I do go the route of creating a ContactType class does a child class need a property for storing it’s Parent’s ID?

Guidance greatly appreciated.

If I am way off here it is because I have never really properly set up a Business Object and am now struggling to fit my environment into what I have read.

Answer 1

The ContactType sounds like reference data. A CaseNote may have 0 or N ContactTypes, and a single ContactType may be assosciated with many CaseNotes. Is that correct?

If so, I would suggest you make a new type called ContactType which contains two properties, Id and Name (assuming thats what the int and string are for):

public class ContactType
{
    public int Id { get; set; }
    public string Name { get; set; }
}

And then in your CaseNote class, I would declare them as a List (or an IList interface):

public IList<ContactType> ContactTypes { get; set; }

To check if they have any ContactTypes you can do:

if( myCase.ContactTypes.Count > 0 )
{
    ...
}