[Serializable]
public class Customer
{
private string m_customerId;
private string m_contactName;
private string m_city;
private List<BusinessObjects.Order> m_orders = new List<BusinessObjects.Order>();
public Customer()
{
}
public Customer(string custId)
{
this.m_customerId = custId;
}
public Customer(string custId, string contactName, string city)
{
this.m_customerId = custId;
this.m_contactName = contactName;
this.m_city = city;
}
public string CustomerID
{
get { return this.m_customerId; }
set { this.m_customerId = value; }
}
public string ContactName
{
get { return this.m_contactName; }
set { this.m_contactName = value; }
}
public string City
{
get { return this.m_city; }
set { this.m_city = value; }
}
public List<BusinessObjects.Order > AllOrders
{
get { return this.m_orders; }
set { this.m_orders = value; }
}
public int CompareTo(Customer cust )
{
return this.CustomerID.CompareTo(cust.CustomerID );
}
// Special implementation to be called by Customer comparer
public int CompareTo(Customer cust, Comparers.CustomerComparerType comparisonType)
{
switch (comparisonType)
{
case Comparers.CustomerComparerType.CustomerId :
return this.m_customerId.CompareTo(cust.CustomerID );
case Comparers.CustomerComparerType.ContactName :
return this.m_contactName.CompareTo(cust.ContactName);
case Comparers.CustomerComparerType.City :
return this.m_city.CompareTo(cust.City );
}
return 0;
}
}
GranadaCoder C# Tidbits 
My only concern with the code is, although it is clean and easy to read you have nearly 4 classes for each data entity you plan to pull out of the database. If you were mapping 100 tables, this would become a difficult to manage project having to change 4 classes everytime the a change was made to a table. As far as using the column name-index mapping in the Layout class, this could haunt someone a little bit if they didn\’t control the database themselves. Although in a good team environment, db admin\’s should never make crazy changes, it would be quite easy for someone to change the column order of a select command, breaking your app in the process.
//Quote//If you
were mapping 100 tables, this would become a difficult to manage
project having to change 4 classes everytime the a change was made to a
table.//End QuoteI understand what you are saying. However, I find this method more maintainable then any shorter version(s). Yes, I have to go to 4 places (the stored procedure, the layout, the controller and then to the business object (to add the property)), but I know exactly where to go, and actually it takes me less time to do this, because I know where everything is, and I am not hunting for it. Obviously, its a subjective choice, but I stick by the model above.//QuoteAs far
as using the column name-index mapping in the Layout class, this could
haunt someone a little bit if they didn\’t control the database
themselves. //End QuoteAnother good observation. If you don\’t have that granular control, then sure, go back to the NamedColumn approach. However, there is a small price to pay every time one needs to do a lookup. When you ask for a value from the datareader with a name (Ex "EmployeeID"), instead of an ordinal (EmployeeLayout.EmployeeID = 0), then there is a lookup involved, you are just encapsulated from it.But here is another gotcha.Select EmpID, DeptID, LastName, FirstName from dbo.EmployeeYour observation is changing the ordinal positions. Like:Select EmpID, DeptID, LastName, MiddleName, FirstName from dbo.EmployeeAnd you are correct.The dba could also do an aliasSelect EmpID, e.DeptID as EmployeeDeptID , d.DeptID as DepartmentDeptID, LastName, FirstName from dbo.Employee left outer join dbo.Department in e.DeptID = d.DeptIDObviously this doesn\’t make a lot of sense from a common sense perspective, but if the dba has to "un-ambigious-ize" a column, then the name changes for the .Net side of things as well.But your observation is valid, and the choice left to the end-developer.I just prefer the Ordinal method, because I believe that gives me the utmost performance, and the Layout gives me readability. And I write the TSQL code myself 99% of the time.A coworker has actually created a code generation tool for all this (as above), which creates the DataLayer, the Layouts, the Controllers, the BusinessObjects, the Collections and the Controller.Deserializers. This is company property unfortunately, so I can\’t post it. But it makes quick work of all this stuff when there is a working database to pull from.I appreciate your comments.
Should you be using Collection<T> or IList<T> instead of List<T> for passing data between layers?