#Data Modeling

1 messages · Page 1 of 1 (latest)

viscid nimbusBOT
#

<@&987246399047479336> please have a look, thanks.

viscid nimbusBOT
#

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

#

You can use </chatgpt:1108714622413963314> to ask ChatGPT about your question while you wait for a human to respond.

whole dome
#

Keep accurate structure of the request, if they are different, then use two classes

manic axle
#

Agreed. readability > compactness

molten hare
whole dome
manic axle
#

I sometimes extend between create and update DTOs (since often update is just + ID), but I do not mix them with response DTOs - personal preference, since more often than not you want to change output without changing input

molten hare
molten hare
manic axle
#

But the moment the use case become more involved than just simple changes on entities I usually go with writing it out with little to no inheritance - readability trumps all in this case IMO

#

Also, these often eventually contain Validation annotations and some OpenAPI annotations and you want to keep that readable as well

#

So unless you have some specific reason why you would inherit between them there is no shame in doing it one way or the other

zenith night
#

keep two views, it's the best way to handle it, especially if your domain evolves over time, you'll be glad you have a request obj and a response obj

static orchid
#

@molten hare You could

#

you can also use extension

#

or just not