The version of SonarJava that is currently used on SonarCloud reports that Persistent entities should not be used as arguments of “@RequestMapping” methods.
Whilst I can see the argument for this rule for controllers that use the standard @Controller annotation I don’t believe that this should apply to @RestController.
When using @RestController it is possible to use @JsonIgnore to control which object attributes can be modified.
I would argue that creating DTO’s creates code duplication. I don’t believe that CWE-915 requires that software uses DTO’s, in fact it specifically refers to using whitelists or blacklists (@JsonIgnore?)
The Spring Data Rest project uses entities as arguments for @RequestMappting methods. Project using Spring Data Rest would automatically fail this rule.
Let’s say I start creating controller methods in the ‘nice’ way, using DTOs, and then converting them to Entities in the controller methods.
So all my controller methods start with some conversion, so I refactor the DTO->Entity conversions.
I create a generic method or even a whole utility class for creating Entity from a DTO.
Looks better, but still all of my controller methods start with a method call to this conversion.
Then I realise that actually Spring has an inbuilt technique for these kind of conversion, so I refactor my conversion class into an ArgumentResolver. So all of these conversions are hidden, the code is clear and nice and readable (and still safe and robust) and the controllers only contains the controller-related logic and then BANG. I got 34 Sonar issues…
Sonar basically punishes me for using Spring in the preferred way…
I had meet a few annoying Sonar issues yet but sooner or later I was able to accept that Sonar is right, and I refactored my code and actually I’m almost always was satisfied with the result.
But this is something else. This is not a coding issue, it’s a design issue. Sonar shouldn’t force me to change my design until it will be able to analyse and understand the WHOLE code as is.