Robust Coding with CBO's and Hydrator

I thought of giving some of my thoughts on DAL and BL designing. Some buzz words today among designers are DTO's and Business Objects (BO's). DTO Vs BO discussion is somewhat controversy and I'm not going to touch that here :). DTO's are smiler to CBO's (Custom Business Objects) that I'm talking in this article.

First I'll refer to a Framework that use CBO's and hydrator design pattern. DotnetNuke is a open source Content Management and Portal development framework (http://www.dotnetnuke.com/). It has a large community and fairly stable product. We have used this for couple of commercial products and customers are happy so do we. The complete data layer of this solution is built on CBO's and a Hydrator. This greatly reduces the size of the code and it's complexity.

If you are using CBO's in your code just think how are you going to populate those objects using a DaraReader. If you are going to hand code all the filling mechanisms definitely it's going to be a nightmare. Just think the the maintenance effort, if you change something in the data model you have to go and change the filling codes as well. You can greatly reduce this complexity by using a hydrator or a helper class with CBO's to automatically fill your CBO's based on reflection.

Few hints on how to write a flexible helper class (Hydrator)

• Use .NET 2.0 Generics to define the FillCollection method

public static C FillCollection(Type objType, IDataReader dr)
where T : class, new()
where C : ICollection, new()

By using generics you can generalize the method to use custom return collections as well as to define concrete objects to be filled at compile time. What I love about this is you can specify generic constraint using where clause.

C# supports five different constraints:

1. Interface constraint - The type argument must implement the specified interface.
2. Inheritance constraint - The type argument must derive from the specified base class.
3. Class constraint - The type argument must be a reference type.
4. Struct constraint - The type argument must be a value type.
5. New constraint - The type argument must expose a public, parameterless (default) constructor.

In the above "where T : class, new()" means the object should be a reference type and it should have a parameterless constructor

• Use Custom Attributes to map object properties to DB columns and to define custom values to null properties. So you don't have to use the same DB column names in your object properties and you can override default null values.

Download Code