to give an update. I think i will also try out "Lombok" now, while i often hesitated to do so.
- Java Records are great to use, because they are short/concise - The immutability of Java Records can be hard to work with when having to work with legacy code (mappings from unclean db to clean api-model are necessary here, and immutability makes it harder for this). - Java Records have no Builder-Pattern, the only have the constructor, and when constructing them manually it is harder to maintain / read. Lombok has a @Builder annotation for Java Records, i will try it :) While Java Records are great to have, i think they still lack some small details, and i may fall back to regular Pojos for the Api But currently everything looks good with the general concept for the api. [email protected] schrieb am Sonntag, 13. Oktober 2024 um 10:14:26 UTC: > Hi Bernd, > > If you need to support mulitple versions of your API and this only > involves the projection part of your query, then you must create a > projection per DTO (preferably as Java Record). > That could be abstracted in versioned repositories (DAOs). > > There would also be a more generic approach to derive the projection > directly from the constructor of the Java Record. But this would require > reflection and is not compile-time checked. > > That’s how I would do it. > > Kind regards, > Simon > > > > On 13 Oct 2024, at 10:16, 'Bernd Huber' via jOOQ User Group < > [email protected]> wrote: > > Hello guys, > > i really loved the following video by Victor Rentea about REST API Design > Pitfalls. > - https://www.youtube.com/watch?v=CNlLWCvazcQ > > in my company we also need to build a Versioned REST-Api, which some > specific Clients can use in a secure way. > > Can someone recommend me an Article or Best-Practice how to integrate Jooq > in such a scenario ? > > I can think of something like ... > - i manually create versioned DTOs (ProductDTOV1, ProductDTOV2, ...) as > simple Pojos. > - i manually write Insert / Update / Delete Methods in my DAOs where i > need to boilerplate down all the fields i want to consider for each > specific case. > - i write a Repository where i Select data and also concretely > (boilerplate) map each field i select into the versioned DTO. > - the Jooq-Codegen-Classes are only used in internal Jobs where REST is > not involved, as they are just an unnecessary middle-man for the REST > use-cases. > > I know that Jooq does support everything i want to do with it, but I often > tend to overabstract, and i hope to find a simple way (even if its > boilerplate) to write REST-Apis with jooq, that do not involve > overabstracted solutions where they are counterproductive. > > I guess the outline i have shown here should work. > > best regards, > > Bernd Huber > > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/ac30997e-16c1-4b74-adb7-03ebf8487255n%40googlegroups.com > > <https://groups.google.com/d/msgid/jooq-user/ac30997e-16c1-4b74-adb7-03ebf8487255n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/1a951657-2bc3-42dc-87ed-1268322468ban%40googlegroups.com.
