Custom Objects and Tiered Development II // 2.0

I’ve taken the 1.1 example (Custom Objects and Tiered Development below), and translated it into a 2.0 example, to take advantage of generics.
First, thanks to Ludwig Stuyck ( ) for his well laid out Article on Generics.
Most of the translation of my 1.1 example to 2.0 came from knowledge gained from his article.
The link to the original location of the article is below.
There is not that much different between the 1.1 example and 2.0 example, except the use of Generics.
For example:


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;



OrderCollection (1.1) has been replaced with
public List<BusinessObjects.Order >
The code sample can be downloaded Here.
 (Right Click , Save As probably works best)
Also see the references in the 1.1 example below.
This entry was posted in Software Development. Bookmark the permalink.

3 Responses to Custom Objects and Tiered Development II // 2.0

  1. Charles says:

    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.

  2. Sloan says:

    //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.

  3. Prajeesh says:

    Should you be using Collection<T> or IList<T> instead of List<T> for passing data between layers?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s