Matt Cashatt
Matt Cashatt

Reputation: 24208

Are there performance implications in creating a common object constructor?

Background

Let's say I have an Address object:

public class Address_Model{
     public int Id {get; set;}
     public string Street{get; set;}
     public string City {get; set;}
     public string State {get; set;}
     public string PostalCode{get; set;}
}

This property is used in several other objects (i.e office object, home object, etc):

public class Office_Model{
     public int Id {get; set;}
     public Address_Model Address{get; set;}
     //. . . (other properties specific to the office model)
}

public class Home_Model{
     public int Id {get; set;}
     public Address_Model Address{get; set;}
     //. . . (other properties specific to the home model)
}

These models live in my BLL. In my constructor, which uses data from my DAL, I currently construct the Address property manually:

public Office_Model GetOffice(int id){

var office = DAL.SomeClass.GettOfficeById(id);

return new Office_Model
{
   Id = office.Id,
   Address = new Address_Model{
       Id = office.Address.Id,
       Street = office.Address.Street,
       City = office.Address.City,
       State = office.Address.State,
       PostalCode = office.Address.PostalCode
   }
}

}

public Home_Model GetHome(int id){

var home = DAL.SomeClass.GettHomeById(id);

return new Home_Model
{
   Id = home.Id,
   Address = new Address_Model{
       Id = home.Address.Id,
       Street = home.Address.Street,
       City = home.Address.City,
       State = home.Address.State,
       PostalCode = home.Address.PostalCode
   }
}

}

In order to increase code maintainability (e.g. not having to add a new property like Street2 to all places where an Address_Model is constructed), I would like to create a common method to construct an address model:

public Address_Model GetAddressModel(DAL.SomeClass.Address address){

     return new Address_Model{
           Id = address.Address.Id,
           Street = address.Address.Street,
           City = address.Address.City,
           State = address.Address.State,
           PostalCode = address.Address.PostalCode
     }

}

Now my BLL getter methods look more like this:

  public Office_Model GetOffice(int id){

    var office = DAL.SomeClass.GettOfficeById(id);

    return new Office_Model
    {
       Id = office.Id,
       Address = GetAddressModel(office.Address);
    }

    }

    public Home_Model GetHome(int id){

    var home = DAL.SomeClass.GettHomeById(id);

    return new Home_Model
    {
       Id = home.Id,
       Address = GetAddressModel(home.Address);
    }

    }

Question

Will delegating this construction operation have negative performance implications? I am new to performance profiling and have just learned about boxing and unboxing; I am not sure if that type of performance degradation will apply to what I am doing here.

Obviously, I have simplified this example to a great degree. In reality there would be many more nested objects that need constructing.

Upvotes: 0

Views: 107

Answers (1)

Yuval Itzchakov
Yuval Itzchakov

Reputation: 149538

Boxing, from MSDN:

Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type.

As your Address object is a reference type (marked as a class and not a struct), and you expect to receive a Address type as an argument, there will be no boxing occuring in your code. More so, the JIT compiler may decide to inline your method call, which will eliminate creating a new stack frame for that call all together.

Upvotes: 2

Related Questions