Class properties concerning List<T> requests – Class design dilema!

Question

When I need to grab more than one record from table(database), my method populates List of particular class (all of my data access layer methods use List for set based select statements. I Don't use datatable/dataset or xmlDocument approach). So lets suppose next simplified scenario; I have two classes – customer and order with these fields/properties:

Class Customer{
   int IDCustomer
   string CustomerName
   string CustomerAddress
   string CustomerCity
}

Class Order{
   int IDOrder
   int IDCustomer
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
}

So, lets say that we need a method which deliver to the UI (ObjectDataSource) all data from Order Class properties + CustomerName and CustomerCity from Customer class. I want my method from Order class looks like:

public List<Order> SelectAll(){ 
}

so which approach should I use to accomplish this? How to setup Order Class so it contain that two extra properties (CustomerName and CustomerCity) concerning best practices, object oriented paradigm, performance etc. :

APROACH A:

---

Class Order{
   int IDOrder
   int IDCustomer
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
   //--- plus two extra properties of type string
   string CustomerName
   string CustomerCity
}

APROACH B:

---

Class Order{
   int IDOrder
   int IDCustomer
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
   //--- plus extra property of type Customer
   Customer _Customer
}

APROACH C:

---

???

I am on .NET 2.0.

Thank you people for your time.

Answer 1

No question, B. There is a one-to-many relationship between customers and orders - a customer has many orders (list of orders) and an order has one customer (scalar property of type customer).

public class Customer
{
   public Int32 Id { get; private set; }
   public String Name { get; private set; }
   public String Address { get; private set; }
   public String City { get; private set; }

   public IList<Order> Orders { get { return this.orders; } }
   private readonly IList<Orders> orders = new List<Orders>();
}

Class Order
{
   public Int32 Id { get; private set; }
   public String SalesPersonName { get; private set; }
   public Decimal SubTotal { get; private set; }

   public Customer Customer { get; private set; }
}

For the user interface you can then create a separate class that wraps an order like the following.

public class OrderView
{
    private readonly Order order;

    public OrderView(Order order)
    {
        this.order = order;
    }

    public Decimal SubTotal { get { return this.order.SubTotal; } }
    public String CustomerCity { get { return this.order.Customer.City; } }
    // ...
}

Answer 2

I have no problem creating another class that flattens the query whichs acts as a viewmodel.

Answer 3

This sounds like a job for an ORM.

Answer 4

If you allow that a one-to-many customer to order relationship exists, a customer class that has-a list of orders follows. While this slightly deviates from your original request, you'll probably have an easier time of manipulating a customer and the orders it contains rather than duplicating members from the parent.

Class Customer{
   int IDCustomer
   string CustomerName
   string CustomerAddress
   string CustomerCity
   List<Order> orders;

   public List<Order> SelectAll(){ return orders; }
}

Class Order{
   int IDOrder
   //int IDCustomer -not necessary as parent contains this info
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
}

Answer 5

Because this is a design question I think that there is more information needed to give a complete answer because I think that it depends on the circumstances.

If you already have the Order objects and the Customer objects loaded and use them for different things in the presentation layer then creating a specialized class to flatten the display data is a good solution.

If you are loading the information to display a list of orders and need the customer information on each order, then I would have to ask why you don't just create a CustomerOrder class that has the relevant fields on it and just load that to begin with because you are not going to use the extra data of Customer anyway.

All these design decisions depend on external factors. In the end, I would say that the right design decision is usually the simplest one that meets your needs.