Best practices for displaying Foreign Key object names in c# objects

Question

I have a method called GetCustomer that returns a Customer object.

Customer object is as below.

Public class Customer
{
  public int Id { get; set;}
  public string Name { get; set;}

  public int CompanyId { get; set;}
}

Lets say Customer is related to a Company and I have to display this customer information on the screen UI. Now, when I call the GetCustomer method I only get back the details about the Customer. On the screen, I also need to display the companyname that this customer belongs to.

One easy way to do this would be to have a property called CompanyName in the customer object and fill it from your datalayer method. But I'm not sure if thats best practice. If the customer also belongs to a department , now I need to have DepartmentId and DeptName as properties. Ids are a must since sometimes I need to send the Id to get the full Dept/Company object.

I don't want to have the full objects for Department and Company in the Customer object.

I assume this is a common scenario where a particular object is linked to others using an ID and when you bring back the main object, you just need to display the name from the other linked objects.

What is the best to way to handle this. My main intention is to avoid an (or more) extra database call.

I'm NOT using Linq or Entity Framework , just regular ADO.NET .

Answer 1

This situation depends on your goals as;

1 - if you want to avoid extra DB calls, you have to code your UI via your db communicator with only one instance, open it only once and flush its members (adapter, command ..etc.) every time after making DB calls and close connection at the end of data transfers.

2 - for other purpose of your question, use lazy loading. put only id's on your entity and initialize and use the id's belonging entity if needed!

For example:

public class Customer
{
  public int Id { get; set;}
  public string Name { get; set;}

  public int CompanyId { get; set;}
}

public class Company
{
  public int CompanyId;
  //company fields
}

// .. on your business layer if you need to use Company data:
// examine your Customer instance as "customer"

Company userCompany = GetCompanyWithId(customer.CompanyId);

but as you no doubt of your guess, data that is going to load is depends of your needs. Think simple. If your only need is Department and Company names, than you can create a view on your DB and can call it on your code. You can create an entity as CustomerWithFullData and you can put a Customer and a Department etc. in this entity and when you need to show full data you can fill this with DB View. Or dont bother to create entities. If you dont need entity, Call DB View directly DataSet and bind Tables. So you can transfer data collection work to DB and this is what we want to do.

As i said before, think simple.

Answer 2

What I would do is to retain an OO structure at the level of your business objects, and modify your DAL to return all the information you need with a single DB round-trip.

For example, you could have a stored procedure that returns two result sets: one for the Customers, and another for the Companies they reference. You could use table valued parameters to pass the SP a list of one or more Customers to look-up.

Depending on the size of your DB and your performance requirements, you also might be able to read the entire Customer and Company tables into memory when the app starts, cache the results, and manage insert/update/deletes against that data.