How to model Data Transfer Objects for different front ends?

Question

I've run into reoccuring problem for which I haven't found any good examples or patterns.

I have one core service that performs all heavy datasbase operations and that sends results to different front ends (html, silverlight/flash, web services etc). One of the service operation is "GetDocuments", which provides a list of documents based on different filter criterias. If I only had one front-end, I would like to package the result in a list of Document DTOs (Data transfer objects) that just contains the data. However, different front-ends needs different amounts of "metadata". The simples client just needs the document headline and a link reference. Other clients wants a short text snippet of the document, another one also wants a thumbnail and a third wants the name of the author. Its basically all up to the implementation of the GUI what needs to be displayed.

Whats the best way to model this:

1. As a lot of different DTOs (Document, DocumentWithThumbnail, DocumentWithTextSnippet)
   • tends to become a lot of classes
2. As one DTO containing all the data, where the client choose what to display
   • Lots of unnecessary data sent
3. As one DTO where certain fields are populated based on what the client requested
   • Tends to become a very large class that needs to be extended over time
4. One DTO but with some kind of generic "Metadata" field containing requested metadata.

Or are there other options?

Since I want a high performance service, I need to think about both network load and caching strategies.

Does anyone have any good patterns or practices that might help me?

Answer 1

Is there any noticable cost to creating a DTO that has all the data any of your views could need and using it everywhere? I would do that, especially since it insulates you from a requirement change down the line to have one of the views incorporate data one of the other views uses

ex. Maybe your silverlight/flash view doesn't show the title itself b/c it's in the thumb now, but they decide they want to sort by it later.

To clarify, I do not necesarily think you need to pass down all of the data every time, but I think your DTO class should define all of them. Just don't fall into the pits of premature optimization or analysis paralysis. Do the simplest thing first, then justify added complexity. Throw it all in and profile it. If the perf is unacceptable, optimize and try again.

Answer 2

What I would do is give the front end the ability to request the presence of the wanted metadata ( say getDocument( WITH_THUMBNAILS | WITH_TEXT_SNIPPET ) )

Then this DTO is built with only this requested information. Adding all the possible metadata is as you said, unacceptable.

I will surely stay with one class defining all the possible methods (getTitle(), getThumbnail()) and if possible it will return a placeholder when the thumbnail was not requested. Something like "Image not available".

If you want to model this like a pattern, take a look at the factory patterns.

Hope this helps you.