You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Ed Cable (Jira)" <ji...@apache.org> on 2023/04/04 15:55:00 UTC

[jira] [Updated] (FINERACT-1586) Reduce Boilerplate Code by Introducing lombok to Reduce getters/setters and Mapstruct to map REST DTO to Entity Objects

     [ https://issues.apache.org/jira/browse/FINERACT-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ed Cable updated FINERACT-1586:
-------------------------------
    Labels: full-time gsoc2023 mentor  (was: full-time gsoc2022 mentor)

> Reduce Boilerplate Code by Introducing lombok to Reduce getters/setters and Mapstruct to map REST DTO to Entity Objects
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: FINERACT-1586
>                 URL: https://issues.apache.org/jira/browse/FINERACT-1586
>             Project: Apache Fineract
>          Issue Type: Improvement
>            Reporter: Rahul Goel
>            Priority: Minor
>              Labels: full-time, gsoc2023, mentor
>             Fix For: 1.9.0
>
>
> Lombok could help us to not only reduce a large amount of code, but also to fix a couple of inconsistencies in the code base:
>  * getters/setters with non-standard characters (e. g. underscores)
>  * getters/setters with typos
> The layered architecture of Fineract requires mapping between REST DTO classes and internal entity classes. The current code base contains various strategies to achieve this:
>  * private functions
>  * static functions
>  * mapping classes
> All of these approaches are very manual (and error prone) and difficult to maintain. Mapstruct can help here:
>  * throw errors at compile time (missing new attributes, type changes etc.)
>  * one common concept (easier to understand)
>  * reduce manually maintained code and replace mostly generated code
> Challenges:
>  * maintain immutability (especially in DTO classes)
>  * should we fluent builder pattern?
>  * backwards compatibility
>  * these improvements cannot be introduced as one pull request, but have to be split up at least at the “module” level (clients, loans, accounts etc.). This would result in approximately 30 pull requests; if we split up Lombok and Mapstruct then it would be 30 PRs each (=60); we would need this fine grained approach to make a transition as painless as possible
>  * some classes are maybe beyond repair (e. g. Loan.java with 6000 lines of code, the smaller part getters/setters and a long list of utility/business logic functions)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)