David Laing's blog » Architecture

DTOs: To Flatten Or Not To Flatten?

mrdavidlaing — Tue, 20 Apr 2010 06:58:39 +0000

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.

[-]^?View Code CSHARP

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.

Flattening with “nulls”

[-]^?View Code CSHARP

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.

Multiple specific MarketWithXYZ DTOS

[-]^?View Code CSHARP

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

Property Bags

[-]^?View Code CSHARP

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

Utils anti-pattern & AutoMapper

mrdavidlaing — Tue, 02 Jun 2009 09:18:41 +0000

These are more for my reference purposes – hopefully you’ll find them useful:

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

The Simplest thing that could Possibly work

mrdavidlaing — Fri, 27 Jun 2008 12:57:26 +0000

Jay has a good discussion concerning the design dilemma we often face considering the “simplest thing that could possible work”. Is it appropriate to implement a simple half baked solution that we know we will throw away as requirements become more defined? Or should we start out with a more complex pattern that will give us more flexibility?

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.