A design pattern for data binding an object (with subclasses) to asp.net user control

Question

I have an abstract class called Address and I am deriving three classes ; HomeAddress, Work Address, NextOfKin address.

My idea is to bind this to a usercontrol and based on the type of Address it should bind properly to the ASP.NET user control.

My idea is the user control doesn't know which address it is going to present and based on the type it will parse accordingly.

How can I design such a setup, based on the fact that, the user control can take any type of address and bind accordingly.

I know of one method like :- Declare class objects for all the three types (Home,Work,NextOfKin). Declare an enum to hold these types and based on the type of this enum passed to user control, instantiate the appropriate object based on setter injection.

As a part of my generic design, I just created a class structure like this :-

I know I am missing a lot of pieces in design. Can anybody give me an idea of how to approach this in proper way.

Answer 1

In general, you shouldn't. The user control should bind to a concrete type.

A better approach would be to have the base address bits be their own class, and then compose 3 classes for the optional bits, each containing a base address class as a member. The user control can then defer the rendering of the address bits to some sub-control.

Or better yet, simply include the home/work phones and next of kin (and leave them blank if unused). It's not as though those elements are mutually exclusive (or should be anyways...).

Answer 2

Looks like a candidate for a Strategy Pattern to me. In a simplistic approach, use delegates to perform the binding based upon type.

It is just as you demonstrate in your diagram whereby the point of the strategy pattern is to encapsulate behavior, ensure class not doing more than one thing, and to use Delegate Pattern to designate a specific interface and concretes to perform a specific function.

Answer 3

I think your best bet would be to define an abstract class that represents an address and the type of address:

public abstract class Address { public abstract string Type { get; } public abstract IEnumerable<string> FieldLabels { get; } public abstract IEnumerable<string> FieldValues { get; } }; 

which you might derive from like this:

public class HomeAddress : Address { public string FirstLine { get; set; } public string ZipCode { get; set; } public override string Type { get { return "HomeAddress"; } } public override IEnumerable<string> FieldLabels { get { List<string> tmp = new List<string>(); tmp.Add("First Line"); tmp.Add("Zip Code"); return tmp; } } public override IEnumerable<string> FieldValues { get { List<string> tmp = new List<string>(); tmp.Add(FirstLine); tmp.Add(ZipCode); return tmp; } } }; 

Any GUI element can then simply be passed an object as a base class pointer, and retrieve and display the address type and address fields.

If there are fields that always appear in all address types then they could be defined in the base class with only optional/variably present fields retrived through the IEnumerable properties.