C# business objects and collections

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 :).

Answer 2

You have several different questions in one here, I will try to answer most.

In regards to problems using List<T> - the framework has a ReadOnlyCollection<T> that is useful in exactly your situation. This is a collection that does not allow adding or removing once created.

In regards to CRUD operation responsibility - that should belong to your data layer, not any of your objects (see SRP - Single Responsibility Principle).

Answer 3

The way I do it is: each object that has children objects contains a list of them, and each object with a parent contains a property with its type. Adding is done by populating an object (or an hierarchy of objects) and sending to the DAL for persistence if desired. The CRUD operations are all in the DAL, which is agnostic of the object types but uses such types to determine which tables, columns, etc to access. Deleting is the only thing dealt with differently by setting an object's Deleted property which triggers the DAL to remove it.

Now regarding business logic - it does not reside with the objects themselves (the DAOs) but rather it is done by classes that receive or gather such DAOs when necessary, perform their work and send the DAOs back to the DAL for updates.