[JAVA] Frühling mit Kotorin --- 8. Aufbewahrungsschicht

Übersicht / Beschreibung

Spring with Kotorin --7 Service wurde geändert, um zu vermeiden, dass sich die Verantwortlichkeiten auf ein einziges Modul konzentrieren. Der Grund ist, zu vermeiden, ein ** Fat Controller ** mit geringer Wartbarkeit, Skalierbarkeit und Lesbarkeit zu werden. Zu diesem Zweck haben wir die Anwendungslogik von der Controller-Schicht getrennt und eine ** Service ** -Schicht bereitgestellt.

Dies ermöglicht es, die zu fokussierenden Funktionsbereiche in der Controller-Schicht und der Service-Schicht zu trennen.

Betrachten Sie nun die neu erstellten Verantwortlichkeiten der Service-Schicht.

Die Rolle der Serviceschicht besteht darin, eine andere "Geschäftslogik als das Akzeptieren von Anforderungen" zu handhaben. Mit anderen Worten, so wie es ist, wird die Persistenzverarbeitung des Ergebnisses der Geschäftslogik auch in dieser Sevice-Schicht durchgeführt.

Übrigens, wenn die Serviceschicht den Datenbereich kennt, der beibehalten werden soll, Es ist notwendig, entsprechend der Art des Zielbereichs zu entwerfen.

Außerdem wird die Abhängigkeit von der Art des Außenbereichs stärker und der Einflussbereich wird größer, wenn Änderungen vorgenommen werden. Wenn Sie beispielsweise eine Datenbank als Beispiel für den Wechsel von Oracle DB zu MySQL verwenden, ist ein Design erforderlich, das die Unterschiede in den Dialekten berücksichtigt.

In Anbetracht der Rolle der Serviceschicht ** Geschäftslogikverarbeitung ** ist es einfacher zu entwerfen und zu warten, wenn das Ergebnis transparent verarbeitet werden kann, ohne das Ziel der Ergebnispersistenz zu kennen.

Eine ** Repository ** -Schicht wird als Mechanismus bereitgestellt, um den Persistenzprozess von dieser Service-Schicht zu trennen.

Annahme / Umwelt

Laufzeitversion

• Kotlin : 1.3.11
• SpringBoot : 2.1.1.RELEASE

Spring Dependencies

• Web
• Actuator
• JDBC
• JPA

Entwicklungsumgebung

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

Beim Einrichten der Repository-Schicht wird diesmal die Datenbank als Persistenzbereich ausgewählt. Der Kürze halber verwenden wir die H2-Datenbank und führen sie im eingebetteten Modus aus.

Vorgehensweise / Erklärung

Dependency Fügen Sie build.gradle die folgende Abhängigkeit für den Datenbankzugriff hinzu.

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

Fügen Sie außerdem die folgende Abhängigkeit hinzu, um die H2-Datenbank zu verwenden.

• com.h2database:h2

Datenbankdefinition

Fügen Sie application.yml die folgenden Definitionen für die H2-Datenbank hinzu.

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

Repository-Schicht

Die folgende Schnittstellendefinition wurde erstellt, um eine Ebene für die Persistenzverarbeitung bereitzustellen.

interface MessageRepository : CrudRepository<Message, String>

Ermöglicht die Arbeit mit Entitäten, die Daten über diese Schnittstelle beibehalten.

Serviceschicht

Von der Service-Schicht aus wird die Entität über die Instanz der injizierten Repository-Schicht betrieben.

@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
        ))
)

Zusammenfassung / Rückblick

Sie können sehen, dass der Code viel einfacher geworden ist als vor der Trennung, indem Sie die Rollen als Controller / Service / Repository separat entwerfen. Auf diese Weise kann verhindert werden, dass das Modul aufgebläht, Spaghetti-codiert und die Skalierbarkeit verringert wird.

Diese Quelle

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