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

My opinion is that you should nest only when you'll be routinely calling a method on the nested object.

If all you will do with the nested object is to get some properties of it, then you shouldn't have it nested and should store the properties directly.

Answer 2

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.

Answer 3

It appears from your code sample that you're setting the supervisor Employee object externally (i.e. through the property setter), so I think this design is OK. If you were automatically instantiating the supervisor object (by, say, hitting the database) every time you created the "outer" Employee object, you would have a potential problem.

Answer 4

I believe the following Business Object (Data Transfer Objects) sparked the email:

    /// <summary>
    /// Manufacturer Data Transfer Object
    /// </summary>
    public class MfgBO {
        public int Id { get; set; }
        public string Name { get; set; }
        public bool Active { get; set; }
    }
  }

public class TypeBO {
        public int Id { get; set; }
        public string Name { get; set; }
        public bool Active { get; set; }
    }


 public class ModelBO {
        #region Private Variables

        private int mmtId = -1;
        private int id = -1;
        private string name = String.Empty;
        private bool active = false;
        private MfgBO mfg = new MfgBO();
        private TypeBO type = new TypeBO();

        #endregion
        // Getter and setters below

Looking at this the ModelBO holds the MfgBO and a TypeBO because a model cannot be complete without the info. What he is recommending is in the ModelBO instead of having MfgBO or TypeBO, we should have a variable of int MakeID, string MakeName, int DeviceTypeId, string DeviceTypeName, etc, basically retyping fields that already exist in MfgBO and TypeBO objects.

To my limited OOP knowledge it makes more sense to use the MfgBO and TypeBO. Which is better way for my own personal knowledge? Is having the MfgBO and TypeBO in MakeBO will actually use more memory and "potentially crash the server"?

Answer 5

You could create the object only if you explicitly access it.

public BusinessObject Item
{
    get
    {
        if (_Item == null)
            _Item = new BusinessObject();

        return _Item; 
    }
}
private BusinessObject _Item;