API-Versionierung in Spring Boot, wie vermeidet man Codeduplizierung (SonarQube Code Duplication)?Java

Java-Forum
Anonymous
 API-Versionierung in Spring Boot, wie vermeidet man Codeduplizierung (SonarQube Code Duplication)?

Post by Anonymous »

Ich habe einen Microservice für Spring Boot. Sehr oft müssen wir eine zweite Version der API (v2) veröffentlichen, die sich nur geringfügig von der ersten (v1) unterscheidet. Zum Beispiel einfach durch Ändern eines an die Geschäftslogik übergebenen Flags, während der Hauptablauf der Anforderungsverarbeitung nahezu gleich bleibt.
Es beginnt normalerweise so:

Code: Select all

@RestController
@RequestMapping("/api/v1")
public class OldControllerV1 {
private final MyService service;

@PostMapping("/process")
public ResultDto process(@RequestBody RequestDto request) {
// ... lots of different validation logic ...
service.execute(request);
}
}
Wenn Leute es eilig haben, eine Veröffentlichung zu versenden, kopieren sie oft einfach den Code, fügen ihn ein und erstellen einen ähnlichen Controller für v2, indem sie einen zusätzlichen Parameter an die Serviceschicht übergeben (in unserem Fall einen einfachen booleschen Wert, um festzustellen, ob es sich um die alte Version handelt).
Am Ende sieht es in etwa so aus:

Code: Select all

@RestController
@RequestMapping("/api/v1")
public class OldControllerV1 {
private final MyService service;

@PostMapping("/process")
public ResultDto process(@RequestBody RequestDto request) {
// ... lots of common validation logic ...
service.execute(request, true);   // true == old mode
}
}

@RestController
@RequestMapping("/api/v2")
public class NewControllerV2 {
private final MyService service;

@PostMapping("/process")
public ResultDto process(@RequestBody RequestDto request) {
// ... the same validation logic copied from v1, maybe slightly different ...
// The only real difference:
service.execute(request, false);  // false == new mode
}
}
An diesem Punkt schlägt die CI-Pipeline normalerweise fehl (beim Schritt der statischen Analyse).
Wenn das Projekt SonarQube mit strengen Regeln (Quality Gate) hat, blockiert es den Build aufgrund der Codeduplizierung – die Methodenkörper sind fast identisch.
Das ist eigentlich fair – eine solche Duplizierung verstößt gegen die Grundsätze sauberen Codes und macht zukünftige Änderungen schmerzhaft, da Sie mehrere Stellen bearbeiten müssen.
Die Frage lautet also:
Wie können wir diesen Code richtig umgestalten, damit wir:
  • Codeduplizierung eliminieren
  • Spring-Annotationen ordnungsgemäß funktionieren
  • Die Lösung erweiterbar machen (einfaches späteres Hinzufügen von Version 3, Version 4 usw.)

Quick Reply

Change Text Case: 
   
  • Similar Topics
    Replies
    Views
    Last post