C# (OOP) Nested Business Objects

Question

I received the following email today from a co-worker. My question is this accurate. Nesting Business Objects is bad practice? Can anyone shine in on this?

Nested Objects When any variable is created within C# it takes up a piece of memory on the Web Server. Since we will have many tools running on the same server, it is even more important to ensure we are not creating objects if we don't plan on using them.

Using the second employee object above as an example… If we also needed to know the employees Supervisor ID.. (and that was all the tool was populating and using) we would want to ensure the Employee class contains the appropriate information, along with taking into consideration Memory and Processes in the tool.

We would add the 'supervisorId' string variable to the Employee class, and add the appropriate Getters and Setters.

On the flip side, we would want to shy away from nesting another object within the employee object. Such as: public class Employee { private string firstName; private string lastName; private string empId; private Employee supervisor;

    public string FirstName {
        get { return firstName; }
        set { firstName = value; }
    }

    public string LastName {
        get { return lastName; }
        set { lastName = value; }
    }

    public string EmpId {
        get { return empId; }
        set { empId = value; }
    }

 public Employee Supervisor{
     get { return supervisor; }
     set { supervisor = value; }
 }
  }

In this case we may not always use the values within the 'Supervisor' instance of the Employee object, but the variables are created in memory. This can have a potentially catastrophic effect on performance.

There are 'some' cases where nesting of objects is necessary: Example: (Category :: Question) Where each category could have an array list of questions assigned to it.

Answer 1

The short answer to your general question of

Is it bad to nest business objects?

is no.

The long answer is that is sounds like your team is suffering from premature optimization. You need to design your business objects to mirror your business domain. All the behaviors in your business domain should be exemplified in your business layer. Once you've achieved that goal, you can then do performance testing. Actually measure what parts of your system is too slow, and then optimize those parts. Don't get caught up in preoptimizing your business logic before you've even had a chance to get it laid out.

Design and implement, then performance test and then optimize when you find unacceptable slowness.