views:

71

answers:

1

I have an MVC2 n-tier application (DAL, Domain, Service, MVC web) using a DDD approach (Domain Driven Design), having a Domain Model with repositories. My service layer uses a Request/Response pattern, in which the Request and Response objects contain DTO's (Data Transfer Objects) to marshal data from one layer to the next, and the mapping is done via help from AutoMapper. My question is this: what shape should a DTO typically take? Can it have nested/complex DTO's as well or should it strictly be a flat projection? Or possibly a mixture of both? Also, what are the main reasons for having a flat DTO vs a more complex/nested DTO?

For instance, suppose I had a domain such as the following:

public class Employee
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Company Company { get; set; }
}
public class Company
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string State { get; set; }
}

There are three different ways I've thought of modeling the Response object.

Option 1 - the DRYest option:

public class GetEmployeeResponse
{
    public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}

From the research I've done, it would be inappropriate for a DTO to take a similar shape as the domain object(s) as demonstrated above.

Option 2 - a flattened projection of the domain (anti-DRY):

public class GetEmployeeResponse
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string CompanyName { get; set; }
    public string CompanyAddress { get; set; }
    public string CompanyCity { get; set; }
    public string CompanyState { get; set; }
}

This is more simple, like a DTO apparently should be, but ultimately makes for more DTOs.

Option 3 - a mixture of both:

public class GetEmployeeResponse
{
    public EmployeeDTO Employee { get; set; }
    public CompanyDTO Company { get; set; }
}

This allows for the code to be a little bit more dry, reusable and manageable, and doesn't expose my domain structure to the end user. The other main benefit is that other responses, like GetCompanyResponse could simply return CompanyDTO, without having to make a copy of all those properties, similar to option 2. What do you think? Which option of these (if any) have you taken and/or have worked for you? If these Request/Responses later get exposed as WCF service methods, does your answer change?

+4  A: 

My personal preference would be to try and keep it flat as possible with only the required data being transfered. having said that I have used deeply nested DTO in the past because it made sense at the time and fitted the requirements. so I guess it comes down to "it depends". At the end of the day go with what makes sense for the application at hand. No point trying to shoe horn data into a DTO convention that doesn't fit what you are tying to achieve.

Nathan Fisher
Aka - Don't throw common sense out the window just to achieve an ambiguous and vague design pattern ( DTOs ). ;) How do you store hierarchical information ( categories of products ) in a flat DTO?
jfar
@jfar One of the factors that I look at, is the chattiness of the application. If there is a lot of traffic over the wire (ie the client requests many little pieces of info) just to display the one page of infomation the I would look to consolidate that into one request for info and return the data in a format that suited.
Nathan Fisher
@jfar If it suited the I would probably denormalise, so that you included the category as part of the product. As I said in my answer I prefer to keep it as flat as possiblebut that does'nt mean that is should be flat as a pancake. If having a heirarchial DTO makes it eaiser to write and maintain the code in your language of choice then I would choose that route as I have in the past when using webservices with MS InfoPath. Trying to flatten the DTO didn't make sense in the that case. the data needs of the application defines the DTO.
Nathan Fisher