record-builder VS MapStruct

The problem with this approach is that the people will have to build crutches like https://github.com/Randgalt/record-builder and by the time Java adds missing features all the codebases will be forever polluted with legacy workarounds that nobody will dare to remove because of backwards compatibility.

It also hinders adoption of new features as people will prefer to maintain consistency in their codebases.

Record builder is pretty good for making builders for your Java 17 records

I always have to bring up RecordBuilder simply because of the included Withers and it being a source generator instead of the Lombok weirdness.

The above is not particularly user-friendly. Luckily compiler plugins can provide the missing feature, most notably RecordBuilder:

For records, instead of lombok you can use https://github.com/Randgalt/record-builder which is a valid annotation processor and will not break on JDK changes

In this particular case you can generate the builder with something like https://github.com/Randgalt/record-builder that is both valid java and lombok-like enough

Records + Record Builder or immutables + the trick to hide the implementing class w/sealed are your friend. Both the mutability and naming conventions this generates are vomitus.

Did you use https://github.com/Randgalt/record-builder ?

Try my annotation processor. It generates withers. https://github.com/Randgalt/record-builder

I personally don't use that one much, but you could use this library instead.

You do not have to write the boilerplate code mapping the fields between your DTO and the other layers of your application. MapStruct can do it for you.

> You don't need to make DTOs when you don't have to, using AutoMapper is considered a bad practice and is heavily discouraged (if you do have to use a tool like that, there are alternatives like Mapperly which are zero-cost to use and will give you built-time information on what doesn't map without having to run the application).

The thing is, that you'll probably have entities mapped against the database schema with data that must only conditionally be shown to the users. For example, when an admin user requests OrderDetails then you'll most likely want to show all of the fields, but when an external user makes that request, you'll only want to show some of the fields (and not leak that those fields even exist).

DTOs have always felt like the right way to do that, however this also means that for every distinct type of user you might have more than one object per DB table. Furthermore, if you generate the EF entity mappings from the schema (say, if you handle migrations with a separate tool that has SQL scripts in it), then you won't make separate entities for the same table either. Ergo, it must be handled downstream somewhere.

Plus, sometimes you can't return the EF entities for serialization into JSON anyways, since you'd need to introduce some additional parsing logic, to get them into a shape that the front end wants (e.g. if you have a status field or something, the current value of which is calculated based on 5-10 database fields or other stuff).

Not to say that some of those can't be worked around, but I can't easily handwave those use cases away either. In Java, MapStruct works and does so pretty well: https://mapstruct.org/ I'd rather do something like that, than ask ChatGPT to transpose stuff from DDL or whatever, or waste time manually doing that.

I found some "tricks" to write less code, hence less code to maintain if there are any changes. Also less code with bugs just by changing the inputs.

For example, OpenAPI spec file + OpenAPI generator (https://github.com/OpenAPITools/openapi-generator). Any changes in the OpenAPI spec are reflected in the final code with a build step.

Another example: MapStruct (https://mapstruct.org/) to avoid passing data from Entity classes to DTO and back. Saves looots of boilerplate code.

Which are your tricks?

In Java (woof..) we have MapStruct (https://mapstruct.org/). Anything like that in Python? I think maybe the Sqlalchemy mapping in Litestar2 is the closest I've seen.

Done right i can look something like mapstruct for example. But like any other feature you need to get a feeling for when it's a good idea to use it.

We are using mapstruct but it sucks when you have protobuf :/

You all beat me to MapStruct and Testcontainers. Honorable mention to RxJava, which I use in Desktop apps.

For the mapping, I'm using Mapstruct, I got the instance example from their examples they use INSTANCE as constant.