Is it ok to make methods in DTO classes?

Question

Software design

Is it ok to make a static factory in a DTO class? Or a constructor with parameters?

My special case is this: I receive JSON from an external system and want to create an internal DTO object based on JSON. It is very tempting to shove the parsing logic directly into the DTO (constructor or static method), but I'm not sure if this is architecturally correct. Right there it would be possible to process the incorrectness of JSON and make some simple mappings. Any wise advice on this?

Answer 1

Wrong, let validators and deserializers be in converters, for example for controllers.
DTOs themselves are just flat stupid objects. unless the mapping and constraints are hung on the fields (as far as the language allows), a la through annotations in PHP / Java
This is how the DTO looks for me for JSON (PHP language)

Usage:

If the framework / language does not allow this to be done outside of the controller, then you can do a similar mapping inside by passing the responsibility of a similar abstraction for conversion