Question

Its often a requirement to have a domain object displayed in various ways on the UI; lists, search results, view and edit pages, as well as in headers, footers and popups. Typically you have several different “views” of the domain object, each with different fields displayed.

Most advice seems to be to use a DTO to get the data when you require a subset or superset. There is a lot of overhead in maintaining DTOs. Is it a bad approach to simply fill the properties of the domain object required for each scenario. For instance you might use a profile to say what properties should be included, eg:

service.GetDomainObjects(int listID, Profile.ListProfile);
service.GetDomainObjects(string searchParam, Profile.SearchProfile);

Answer 1

For me what this comes down to is where you want the overhead to be, either you are going to have a set of different classes to represent your DTOs, or you are going to have a set of methods that each return the same domain object but with different fields being ‘hydrated’.

A couple of questions I’d ask to help make the decision are:

• what is the overhead in hydrating the entire object? Is the added complexity (of DTOs or partially hydrated objects) really worthwhile?
• is anyone else going to be using your code? You don’t to confuse people with paritally hydrated objects, DTOs might be more clear when people come to maintain your code.

I have a slight personal preference for DTOs as I feel the long term maintainance of your system will be easier. If your a one man band, or this is a one off throw away app, I can totally understand not wanting to introduce a bunch of extra classes that will clutter your code.