Fucking dto hell...

Dear C#/.NET developers or any other developers, do you have a fucking smart approach/technique to handle the fucktons of dto classes throughout your webapi and not having to go to 5 different classes if you change some validation attributes ??

Seriously, that is the only thing I like about JS. It just does not fucking care...

EDIT: This rant came across and just fits perfectly: https://devrant.com/rants/686338

.

Our solution is to not use DTO classes.

You need a library that writes boilerplate for you. In Java we use Lombok and Mapstruct. lombok generates the public get/set methods and Mapstruct generates mappings between similar/identical classes with the option to define custom ones and even how to handle null values. The result is that you still need to add fields to the classes, but they map automatically

Additionally, use proper inheritance to build common objects. Then you only need to add fields to the parent class

Alternatively, depending on your framework or whatever you use. If you can serialize your entities into something like json directly with some access restrictions, that works too, and its a single entity, tho chances are you'll need a dto as well

Even more alternatively, use something like graphQL or similar query language that moves the dto definition to FE where they can define a view for them selves

Problem with typeless languages becomes painfully obvious once the code grows.

To begin with its freedom and helps fast development but down the line when you might have dozens of developers you suddenly find that the objects sometimes don’t have all properties populated because some one added a field in one place but not in all and that just cost you 2 days of debugging.

Once there you implement external structure to prevent diversion and your less free than in a strongly typed language.

Think about why both Microsoft, facebook and google have come up with there own takes on type safe javascript. Facebook has their “flow”, microsoft has typescript and before both, google tried dart which is not really js but was an attempt to replace it.

Strict typing is actually a very big help if you use a good editor and with built in refactoring, updating a type is not very hard to do, any moe complex changes are probably required anyway, but might not be obvious to begin with.

And for converting to local classes, its actually not very time consuming, might just feel that way ;)

I wouldn't like to sound like a prick but... You just have to do conception for the software architecture...

On DotNet you can use factories and dependency injection. That's all you need I would say...

In my opinion, the big problem with dynamic weak typed languages is the ease to write running code.
It's languages where anyone can code, even if you have no formal training. So they think everyone can code, and that's not true.

@Hazarth sounds somewhat like Entity Framework (generates classes from database tables or vice versa) and automapper (maps an instance of class A to an instance of class B, will do it automatically for properties with the exact same name and type)

@HisAxelency yes! Exactly. Sorry, Im too used to the technologies we use, I didn't realize I wasnt speaking generaly. The main point there is that if you let all your systems communicate with a common language like json, the property mappers and other boilerplate reductors can take off a lot of the load (tho admitadly its problem specific).

@Voxera I am using Display and validation attributes from ComponentModel namespace. Not sure how to maintain them. I found some kind of metadata thing but that doesnt get evaluated that good in most cases with external libraries. Gonna go the inheritance way. But not sure how to maintain them. I am already using a dto generator. Gonna combine the inheritance and automapper and hope for the best :D

@jotamontecino Creating (even auto creating) classes for e.g. the CreateBookDto request is quite exhausting. Now think of changing the validation attributes applied to the Name property. Well now you gotta go to CreateBookDto, IndexBookDto, EditBookDto, DetailsBookDto... Some kind of thing no editor or refactoring tool can directly help you with. I am currently thinking of coding a library/generator tool to integrate in the linting/build process to handle such cases...

@hypervtechnics are all of these classes actually different?

@jurion we have a similar stack. We have data models and view models, and that's it. Sometimes we don't even have a view model.

@hypervtechnics I was talking about dynamics factory.
DTO are kind of façades for the DB if I'm not mistaken.
So you can have a factory/decorator/dependency injector that'll add the basics/combined functions inside all of your DTO.
So to change how the façade works, you only change the injected functions and the combining inside your factory.

That's I would do on Node or Elixir (and PHP with more framework config).

Didn't I get the problem?

Kinda late to the party, but: When we switched from service pattern to mediator, this problem kinda disappeared. Every UI concern translates into a separate request class, which makes Dto's way better to "distinguish". Also, we developed our own internal framework which allows you to select only the desired properties of a DTO. The other properties are left at default value. Kinda like GraphQL, but with much less overhead. So for the reading operations this makes things way easier.