Sunday, March 25, 2007

Automate your Build and Packaging Process

Check this out great toolset for automate your build and packaging process

Wix ToolSet
Tips and Tricks

Thursday, March 22, 2007

Beauty Of .NET (Extender Controls)

Have you ever wanted to extend functionality of .NET controls ? if so first thing you will do is subclasing the control and implement your functionality. Hmm there is a much more elegant way of doing this by using Extender Controls.

Extender controls allows you to extend functionality of exiting controls in a form without subclasing. You have to only drag the extender control to the form and there you go ..... all the controls in the form are equipped with the new functionality.

The basics are very simple, and you have to build the rest according to your needs. End of this article I have presented some interesting things that can be done using this technique. Extender control is a component so you have inherit your class from a component and implement the IExtenderProvider interface.

public class HelloWorldComponent : Component,IExtenderProvider

IExtenderProvider interface is very simple. You have to only implement the CanExtend method.

public bool CanExtend(object extendee)
if (extendee is Control && !(extendee is HelloWorldComponent))
return true;
return false;

The above will extend all the controls in a form (win or web) with properties extended from extender control. You can introduce one to many properties to controls in a form using one extender control. For introduce a property you have implement two methods Set(Component,String) and Get(Component). ProvideProperty attribute gives names of the properties. Pls refer Extender Controls Tutorial for more details on creating and using extender controls.

Interesting things you can do with Extender Controls

1) UI Security Implementations
2) Two Way Data Binding in ASP.NET for simple controls like text boxes and radio buttons

Have fun.........

Friday, March 09, 2007

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 ( 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