Question

I’m having difficulty wrapping my head around business objects or more specifically, business object collections.

Here’s a quick example of what I’m trying to do.

If I have an Incident Object, this object can have a number of people involved and each of those Person objects can have multiple notes. Notes can’t exist without a Person object and Person objects can’t exist without an Incident Object.

If I have Public List<Note> notes = new List<Note>() then methods such as ADD and REMOVE become available to Person within Incident. I assume that if I was to call those methods on the Notes collection it will simply remove it from the List but not execute any code to actually add/update/delete the employee from the data source. This leads me to believe that I shouldn’t use List but something else?

This also leads me to another question. Where should the actual database CRUD operations reside. Should a Note object have its own CRUD or should the Person object be responsible for it since it can’t exist without it?

I’m a little lost about which way to go and I’d like to get this part right because it will be the template for the rest of the program.

Answer 1

Some great information has been given but one thing that you mentioned that may be confusing you is this:

“If i have Public List notes = new
List() then methods such as ADD,
REMOVE become available to Person
within Incident.”

That all depends on how you design your classes. One thing that you should think about is the way this data relates to one another. That will help you picture your class design.

It sounds like the following:

• One incident can involve many people
• One person can create many notes
• A note is the lowest level and exists due to an incident being created and a responsible person(s) working on that incident.

Incident 1 – many Persons

Person 1 – many notes

You can do this type of relationship in a number of ways. One way may be to actually seperate the objects involved, and then create joined objects.

For instance

public class Incident {
//insert incident fields here
//do not add person logic / notes logic
//probably contains only properties
}

public class Person {
//insert person fields
//private members with public properties
//do not embed any other logic
}

public class Comment {
 //insert comment private fields
 //add public properties
 //follow the law of demeter
}

These classes do not give details to one another, they are just repositories to store this information. You then relate these classes to one another for instance

public class IncidentPersonnel {
List<Person> p;
//add methods to add a person to an incident
//add methods to remove a person from an incident
....
}

Then you may have another class handling the commenting by personnel

public class PersonnelNotes {
List<Note> n;
//other methods...
}

You can go further with this but it may complicate things but I am just giving you another idea of how to handle this.

Try to follow the law of demeter for functions

Encapsulate all of your objects, in addition, your neighbor can talk to you but not much else… This will help keep your classes loosely coupled and makes the thought process a bit simpler for you.

Finally, you mentiond how the CRUD operations should work. This all goes back to your DAL (Data Access Layer). Rather then return rows of data from a table you could then return a referenced object with all of its attributes. Add’s and remove’s work the same way (passing in or out an object). You can use an ORM or write up your own DAL. It all depends on how involved you want to involve yourself :).