I’m busy working on a JSON based API with client libraries in Flex, C# and Javascript (and eventually iPhone, JavaFX etc).

One of the things the API deals with is the concept of a Market. Markets have a number of properties that “belong” to them, simplistically things like MarketId and Name.

public class Market
{
    public int MarketId {get; set;}
    public string Name {get; set;}
}

However, I can see that in using a list of markets, its going to be useful to know related data about the market for things like sorting. For example, when showing a list of markets I’d like to know the volume traded in the last day so I can colour them differently. Or the price change in the last hour etc.

DTO wise, there seem to be several options.

1. Flattening with “nulls”

   public class Market
   {
       public int MarketId {get; set;}
       public string Name {get; set;}
       public decimal? VolumeInLastDay {get; set;}
       public decimal? PriceDeltaLastHour {get; set;}
   }
   

   It seems that over time this approach will lead to very “messy” DTOs where you’re forced to do a lot of “isNull” style checking before attempting to display things.

2. Multiple specific MarketWithXYZ DTOS

   public class MarketWithVolume: Market
   {
       public decimal VolumeInLastDay {get; set;}
   }
   
   public class MarketWithPriceDelta: Market
   {
       public decimal PriceDeltaLastHour {get; set;}
   }
   
   public class MarketWithVolumeAndPriceDelta: MarketWithVolume
   {
       public decimal? PriceDeltaLastHour {get; set;}
   }
   

   An explosion of DTOs, but at least you know exactly what data you’ve got at any instance

3. Property Bags

   public class Market
   {
       public int MarketId {get; set;}
       public string Name {get; set;}
       public Hashtable RelatedData {get; set;}
   }
   
   decimal delta = Market.RelatedData["PriceDeltaLastHour "];
   

   In a way this feels even worse than having multiple null attributes; especially for someone new to the API because you won’t know until run time which data is available.

How have you approached this problem in the past? What works, and what doesn’t? Comments much appreciated.

Update

• Reduced duplication in Multiple specific option using inheritance

If you’re about to name a class **Util; think harder – there is a better name that discribes what that class is for:
Chriss Missal has some advice for you

Faced with the prospect of heaps of left hand side => right hand side code in your DTO of anti-corruption layer? Consider Jimmy Bogard’s Automapper

http://blog.jayfields.com/2008/06/simplest-thing-that-could-possibly-work.html

Jay concludes that you can’t decide which pattern will give you the right flexibility until you have more requirements. So, rather than potentially implement the wrong complex solution, just treat the temporary solution as part of the learning process.

I agree. Like optimising, you need to know the precise requirements before you can choose the right pattern.

Throw away code isn’t wasted; rather its used like scrap paper in the learning process.