DTOs: To Flatten Or Not To Flatten?

April 20, 2010 by mrdavidlaing
Filed under: Architecture, Software Craftmanship 

that is the question…

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.

1
2
3
4
5

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”

    1
2
3
4
5
6
7

    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

    1
2
3
4
5
6
7
8
9
10
11
12
13
14

    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

    1
2
3
4
5
6
7
8

    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

Tags: , ,

Comments

2 Comments on DTOs: To Flatten Or Not To Flatten?

  1. Hibri on Thu, 22nd Apr 2010 4:27 pm

    2. I would try to flatten it where possible, and try to avoid more than
    one dot. I think it makes discovery easier, for an API user.
    Interesting. I’m going to face this issue soon.
    It’s how a consumer would use it. Maybe put yourself into the shoes of
    the API consumer ?
    Or get someone new to write something with the api

  2. OtherDavid on Wed, 26th May 2010 11:45 pm

    3. Related – Why You Shouldn’t Expose Your Entities Through Your Services –
    http://davybrion.com/blog/2010/05/why-you-shouldnt-expose-your-entities-through-your-services/

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!





  • Lets talk!

  • Latest del.icio.us links

    • this, is boomerang 2010/08/22
      Javascript library to measure actual page load time on user's machines