Stop using Data Transfer Objects (DTOs) in your code
<p>Goals and objectives vary a lot depending on your organization's goals and constraints. When I was a consultant, I was essentially “outsourced” to help with a particular project for a short period of time. You get exposed to very diverse projects and different ways of doing things.</p>
<p>Then you realize that everything is debatable, what’s considered clean and efficient in one project is a no-go for another. The usage of Data Transfer Objects (DTOs) where a topic that constantly resurfaced throughout this period. I decided to share my experience around it and when it was causing more harm than good.</p>
<p>Here are my top 5 reasons why you shouldn’t use DTOs and what the alternative is.</p>
<h1>What’s a DTO?</h1>
<p>A DTO is essentially an object that bundles some data together. This packaged bundle is sent from one application to another or within the same application to transfer the data in a structured and easy way. Here’s a <strong>very basic</strong> example of a DTO:</p>
<pre>
// Before DTO
public void AddUser(string firstName, string lastName, int age, ...);
// After DTO
public void AddUser(User user);
public class User
{
public string FirstName {get; set;}
public string LastName {get; set;}
public int Age {get; set;}
}</pre>
<p>Those are essentially used everywhere, here are some common use cases:</p>
<h2>External Contracts</h2>
<p>Let’s say you’re building an API or an SDK, your GET User endpoint will take some arguments to fetch a User from the database. In our implementation, we do not want to expose the internal database ID of the user for security reasons, or we want just want to filter out properties that are not useful</p>
<p><a href="https://anthony-trad.medium.com/stop-using-data-transfer-objects-dtos-in-you-code-62b58f97278e">Click Here</a></p>