Skip to content

Add the ability for the DtoFactory to accept an instance implementing#13220

Closed
metlos wants to merge 1 commit intoeclipse-che:masterfrom
metlos:dto-copy-ctor-from-superifaces
Closed

Add the ability for the DtoFactory to accept an instance implementing#13220
metlos wants to merge 1 commit intoeclipse-che:masterfrom
metlos:dto-copy-ctor-from-superifaces

Conversation

@metlos
Copy link
Copy Markdown
Contributor

@metlos metlos commented Apr 24, 2019

What does this PR do?

Our DTO generator contains copy constructor and our DtoFactory is able to clone a DTO instance into a new deeply-copied one.

But when it comes to converting our JPA entities into the DTOs we use the very verbose DtoConverters sprinkled around the codebase, hand-written and amounting to hundreds of lines of tedious, error-prone code each.

This PR tries to eliminate the need for the DtoConverters by adding the ability to (partially) initialize the DTO instances also from instances implementing some common superinterface with the DTO (typically, our JPA entities implement a common interface with the DTOs) and adding a new DtoFactory.cloneFrom() method that tries to initialize a new DTO instance from an object by checking whether such conversion is possible at runtime.

What we gain by this is several thousands of lines of code potentially removed, if we replace our DtoConverters with this.

What we loose is a little bit of type safety where the check whether a conversion from a certain object to a DTO instance becomes manual and errors only pop up at runtime. On the other hand, our current approach is also error prone because we cannot enforce initialization of newly added properties in all the converters (this is a manual step now, which is automagically handled by this PR).

What issues does this PR fix or reference?

none

a super type of the DTO interface (from which the DTO inherits its getters)
and produce a DTO instance from it.

This should basically eliminate the need for the "asDto()" methods
sprinkled around the codebase and cut on the boilerplate significantly.

Signed-off-by: Lukas Krejci <lkrejci@redhat.com>
@che-bot che-bot added status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. kind/enhancement A feature request - must adhere to the feature request template. labels Aug 6, 2019
@eclipse-che eclipse-che deleted a comment from che-bot Aug 6, 2019
@che-bot
Copy link
Copy Markdown
Contributor

che-bot commented Jan 31, 2020

Can one of the admins verify this patch?

@che-bot
Copy link
Copy Markdown
Contributor

che-bot commented Jul 29, 2020

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 29, 2020
@che-bot che-bot closed this Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/enhancement A feature request - must adhere to the feature request template. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants