[JAVA] Spring with Kotorin --- 8. Couche de référentiel

Aperçu / Description

Spring with Kotorin --7 Service a été modifié pour éviter de concentrer les responsabilités sur un seul module. La raison est d'éviter de devenir un ** Fat Controller ** avec une faible maintenabilité, évolutivité et lisibilité. Pour cela, nous avons séparé la logique de l'application de la couche Controller et fourni une couche ** Service **.

Cela permet de séparer les zones fonctionnelles sur lesquelles se concentrer dans la couche Contrôleur et la couche Service.

Considérez maintenant les responsabilités nouvellement créées de la couche Service.

Le rôle de la couche Service est de gérer «la logique métier autre que l'acceptation des demandes». En d'autres termes, tel quel, le traitement de persistance du résultat de la logique métier sera également effectué dans cette couche de service.

À propos, lors de l'examen de la persistance des données, si la couche de service est consciente de la zone cible à persister, Il est nécessaire de concevoir en fonction du type de zone cible.

De plus, la dépendance vis-à-vis du type de zone externe devient plus forte et la plage d'influence s'élargit lors des modifications. Par exemple, en prenant une base de données comme exemple, le passage d'Oracle DB à MySQL nécessite une conception qui prend en compte les différences de dialectes.

Compte tenu du rôle de la couche Service, ** Traitement de la logique métier **, il est plus facile de concevoir et de maintenir la maintenance si le résultat peut être traité de manière transparente sans connaître la destination de persistance.

Une couche ** Repository ** est fournie comme mécanisme pour séparer le processus de persistance de cette couche Service.

Hypothèse / environnement

Version d'exécution

• Kotlin : 1.3.11
• SpringBoot : 2.1.1.RELEASE

Spring Dependencies

• Web
• Actuator
• JDBC
• JPA

Environnement de développement

• OS : Mac
• IDE : IntelliJ IDEA
• Build : Gradle
• DB : H2 Database

Lors de la configuration de la couche Repository, cette fois, nous ciblerons la base de données en tant que zone de persistance. De plus, par souci de concision, nous utiliserons la base de données H2 et l'exécuterons en mode intégré.

Procédure / Explication

Dependency Ajoutez la dépendance suivante à build.gradle pour accéder à la base de données.

• org.springframework.boot:spring-boot-starter-jdbc
• org.springframework.boot:spring-boot-starter-data-jpa

Ajoutez également la dépendance suivante pour utiliser la base de données H2.

• com.h2database:h2

Définition de la base de données

Ajoutez les définitions suivantes pour la base de données H2 à application.yml.

spring:
  datasource:
    tomcat:
      test-on-borrow: true
      validation-interval: 30000
      validation-query: SELECT 1
      remove-abandoned: true
      remove-abandoned-timeout: 10000
      log-abandoned: true
      log-validation-errors: true
      max-age: 1800000
      max-active: 50
      max-idle: 10
    driver-class-name: org.h2.Driver
    url: jdbc:h2:mem:app;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=TRUE
    username: guest
    password: guest
  h2:
    console:
      enabled: true
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true

Couche de référentiel

La définition d'interface suivante a été faite pour fournir une couche pour le traitement de persistance.

interface MessageRepository : CrudRepository<Message, String>

Vous permet de travailler avec des entités qui conservent des données via cette interface.

Couche de service

À partir de la couche Service, l'entité est exploitée via l'instance de couche Repository injectée.

@Autowired
lateinit var repository: MessageRepository

fun getMessages() : Iterable<MessageDTO> = repository.findAll().map { it -> MessageDTO(it) }

fun insertMessage(messageDto: MessageDTO) = MessageDTO(
        repository.save(Message(
                                title = messageDto.title,
                                message = messageDto.message
        ))
)

Résumé / Rétrospective

Vous pouvez voir que le code est devenu beaucoup plus simple qu'avant la séparation en concevant les rôles en tant que contrôleur / service / référentiel séparément. En concevant de cette manière, il est possible d'empêcher le module de se gonfler, d'être codé en spaghetti et de réduire sa scalabilité.

Cette source

• shinyay/spring-just-rest-kotlin/tree/first-repository-layer