Skip to content
Leonardo Porro edited this page Jan 16, 2023 · 11 revisions

A DTO (Data Transfer Object) is an object designed to carry data. Usually DTOs are plain classes with data properties and no methods or calls, other than annotations or small routines related to serialization or validation.

In the scope of this library a DTO can be the same entity being mapped, or a regular class with a subset of the original entity properties, or an anonymous class, or a dictionary or JSON.

Also, more types can be added using extensions.

Entities are not always DTOs

EntityFramework dropped self-tracking objects long ago, and replaced it by the ChangeTracker. This improvement provided nice clear and light entities which doesn't need to inherit from a specific entity base class.

While a few of these nice and clean entities may work as DTOs, not all entities fit naturally into the DTO role.

Some entities may have sensitive data, like User.Password, or Auditory, other entities have complex types that doens't work well with serialization, such as DbGeography.

There are unwanted fields, such as foreign keys that are specific to SQL technology and look ugly outside of the Data Access Layer.

Another usual problem is that Swagger generates all the fields in the entity and not only the needed for the specific action, for example, Id is not needed for Create method when it is autonumeric or autogenerated Guid).

Create as many DTOs as needed

Developers are often afraid of creating DTOs because the amount of code they need to write the mapping and set the right states. The goal of this library is to simplify that task so creating DTOs is less painful. Some technologies, like GraphQL encourage to have one DTO per action, so for example, Save mutation will have SaveInput, Edit mutation will have EditInput and so.