I have come across quite a few ASP.NET Core WebAPI solutions where there is a inordinate number of Data Transfer Object (DTO) classes. This results in a kind of class explosion which I think can be avoided. Yes, DTOs do have their utility, no doubt. But, many a times as the application evolves and grows, we often end up with numerous DTOs and these DTOs sometimes differ just by a handful of attributes or in some cases they are a simple composition of multiple entities / DTOs.

One of the reasons we have so many such DTO classes is the need to pass data to and from repository and service layer ( between different layers of the application for that matter). In order to find a way around creating yet another DTO, I was exploring some options and realized that Tuples can be used to minimize the creation of DTOs

Tuples have been around in C# for quite sometime now. I am not sure if it is a common knowledge but I recently figured out that you could eliminate quite a few DTOs that we use to ferry data between the layers by leveraging Tuples

Let us take the following scenario of instance.

We have an API, say, GetCustomers which, of course, will return me the list of customers . And, we have an entity, Customer as defined below.

class Customer
{
public int customerId {get; set;}
public string firstname {get; set;}
public string lastname {get; set;}
}

The API response for our GetCustomers API is as below

You would have noticed that the attribute count is expected in the response and this is not present in our Customer class. The repository layer would just return a List but the service layer needs to pass it along with the count attribute to the controller. This is usually where we tend to create a DTO as below.

class CustomerDTO
{
int count;
List customers
}

The only reason for the above class to exist is to ferry the data from repository in a format that the controller is expecting. We can eliminate this class altogether by returning Tuple as below

return new Tuple<int, List>(result.Count,result)

Granted, this is a very trivial scenario and you can add the count attribute in the controller and return an anonymous type also.

Now consider the cases when you need a response that is aggregation of multiple custom types. For instance, if we have two API one to get customer and another to get order details we would have created two DTO for Customer and Order. If a new API is required that gives details pertaining to a particular Customer and all related Orders as response, you might have to create a new DTO again, as below.

public class newDTO {
public int orderCount {get; set;}
public int customerId {get; set;}
public List orders {get; set;}
}

The expected response is

This is exactly what we can avoid by using Tuples like below in the service and repository layer.

RepositoryLayer.cs

var repoResponse = new Tuple<int, Customer customer, List>(count,custResult, orderResult);
return repoResponse;

custResult holds a particular customer’s data and orderResult will be a List

ServiceLayer.cs

.
.
.
//Create a Tuple with three members, count, customer and orders
//repoResponse is the response from your repository(a Tuple)
(int count, Customer customer, List orderList) result = (repoResponse.Item1, repoResponse.Item2, repoResponse.Item3);

return result;
}

From the above service response, the controller can create an anonymous type as below without ever creating a DTO and return the response .

return new { ordercount= serviceResponse.count, customer = serviceResponse.customer.customerId, serviceResponse = serviceResponse.orderList };

It should be noted that, although this approach eliminates the need to create DTO classes, it come at the cost of readability. Your method signatures may not be very elegant and readable. While DTOs will still be the right way to go in some scenarios, for others, Tuples can help.

Hope this helps in reducing a few DTOs at your end.

Cheers!