关于JHipster中OpenAPI生成模型类在Service层方法中合法使用方式的咨询

Great question—this is a common pain point when working with JHipster's default architecture and OpenAPI-generated code. The core issue is that JHipster's ArchTests enforce strict layer separation: service/repo layers can't depend on web-layer classes, but OpenAPI models are placed in the web.api.model package by default. Here are three practical solutions to handle this:

1. Relocate OpenAPI Models to a Shared Package (Recommended) #

This is the cleanest approach because it keeps your architecture aligned while making models accessible to both web and service layers.

Steps: #

• Update the OpenAPI Generator configuration: In your pom.xml, modify the modelPackage (and optionally apiPackage) in the openapi-generator-maven-plugin to a shared package instead of the web layer. For example:

  <plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <configuration>
      <!-- ... other config ... -->
      <apiPackage>com.yourcompany.yourapp.web.api</apiPackage> <!-- Keep API controllers in web -->
      <modelPackage>com.yourcompany.yourapp.shared.model</modelPackage> <!-- Move models to shared -->
    </configuration>
  </plugin>
  

• Adjust ArchTest rules: Open your project's ArchitectureTest.java (usually in src/test/java/com/yourcompany/yourapp) and update the rules to allow service/repo layers to access the shared package. Look for rules like noClasses().that().resideInAPackage("..service..").should().dependOnClassesThat().resideInAPackage("..web..")—add an exception for the shared package:

  @ArchTest
  public static final ArchRule servicesShouldNotDependOnWebLayer = noClasses()
      .that().resideInAPackage("..service..")
      .should().dependOnClassesThat().resideInAPackage("..web..")
      .allowingClassesThat().resideInAPackage("..shared.."); // Add this exception
  

• Regenerate OpenAPI code: Run mvn openapi-generator:generate to refresh the models in the new shared package. Now your service classes can import and use these models without triggering ArchTest failures.

2. Create a Mapping Layer Between Web and Service Models #

If you want to keep strict layer separation (and avoid modifying ArchTests), you can create internal service models and map between them and the OpenAPI web models.

Steps: #

• Define service-layer DTOs: Create your own data transfer objects in the service package (e.g., com.yourcompany.yourapp.service.dto) that mirror the structure of the OpenAPI models.
• Implement mapping logic: Use a library like MapStruct or manual mapping in your web controllers to convert between OpenAPI models and service DTOs. For example, with MapStruct:

  @Mapper(componentModel = "spring")
  public interface OrderMapper {
      OrderDto openApiOrderToOrderDto(com.yourcompany.yourapp.web.api.model.Order openApiOrder);
      com.yourcompany.yourapp.web.api.model.Order orderDtoToOpenApiOrder(OrderDto orderDto);
  }
  

• Service layer uses internal DTOs: Your service methods will accept and return the service-layer DTOs, while the web controller handles the conversion to/from OpenAPI models. This keeps the service layer independent of the web layer, adhering to JHipster's architecture rules.

3. Modify ArchTest Rules to Allow Web Model Access (Less Recommended) #

If you don't mind relaxing the layer separation constraints, you can directly allow service layers to access the web.api.model package.

Steps: #

• Update ArchitectureTest.java: Modify the relevant ArchRule to exclude the web.api.model package from the restriction:

  @ArchTest
  public static final ArchRule servicesShouldNotDependOnWebLayer = noClasses()
      .that().resideInAPackage("..service..")
      .should().dependOnClassesThat().resideInAPackage("..web..")
      .allowingClassesThat().resideInAPackage("..web.api.model.."); // Allow access to models
  

• Note: This approach weakens the intended architecture separation, which could lead to tighter coupling between web and service layers. Only use this if you have a strong reason to avoid the other solutions.

Each approach has its tradeoffs—relocating to a shared package is the best balance of architecture cleanliness and practicality, while mapping adds boilerplate but keeps strict separation. Choose based on your project's needs!

内容的提问来源于stack exchange，提问作者Zicane