Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Lære Trelagsarkitektur | Spring Boot-Grunnleggende
Spring Boot Backend

bookTrelagsarkitektur

Dette gjøres for å skille spesifikk logikk i ulike klasser/pakker, i stedet for å skrive alt i en enkelt klasse.

Rekkefølgen en forespørsel behandles i er ControllerServiceRepository. Deretter returneres responsen i motsatt rekkefølge: Repository -> Service -> Controller. Vi starter implementeringen med Repository-laget.

Repository-nivå

Dette er det laveste laget, hvor vi mottar prosessert data fra Service-laget og lagrer det i databasen.

Disse klassene er merket med @Repository-annotasjonen for å legges til i Spring-konteksten.

Main.java

Main.java

copy
1234
@Repository public class RepositoryLevel { // connect DB }

Eksempel på bruk av Repository

Servicenivå

Dette er hvor kjerne-logikken i applikasjonen utføres. I tjenester behandles eller endres data før det sendes videre til repository-laget.

For tjenester bruker vi @Service-annotasjonen, som deklarerer klassen som en service som inneholder forretningslogikken.

Main.java

Main.java

copy
1234567
@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }

Eksempel på bruk av tjeneste

Kontroller-nivå

Dette laget håndterer den innledende interaksjonen mellom klient og server. Alle forespørsler sendt fra klienten ankommer her, og det er ansvarlig for å motta data gitt av klienten.

Det behandler innkommende HTTP-forespørsler og returnerer HTTP-responser. Kontrollere fungerer som en "bro" mellom klienten og forretningslogikken.

På dette nivået brukes det to annotasjoner for å angi en klasse som en kontroller:

  • @RestController: Angir en klasse som en REST-kontroller, som håndterer HTTP-forespørsler og returnerer data i JSON-format;

  • @Controller: Angir en klasse som en MVC-kontroller, som håndterer forespørsler og returnerer visninger (f.eks. HTML).

Main.java

Main.java

copy
12345678
@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }

@GetMapping-annotasjonen angir URL-en for en gitt forespørsel. Dette betyr at vi legger til den spesifiserte stien /root til domenet, og til gjengjeld mottar vi den tilsvarende siden.

Eksempel på bruk av Controller

Thymeleaf-avhengigheten fra videoen

Her er lenken til Thymeleaf-avhengigheten i Maven-repositoriet.

Men hva skjer hvis du ikke følger denne tilnærmingen?

Teknisk sett, ingenting. Selv om du skriver all forretningslogikk i controlleren, kobler til databasen der, og returnerer responsen til klienten fra samme sted, vil alt fungere på samme måte.

Likevel vil du sannsynligvis ikke huske hva du skrev der etter noen uker, fordi all applikasjonslogikk vil være på ett sted, noe som er svært upraktisk.

Sammendrag

Trelagsarkitektur gir en tydelig separasjon av ansvar mellom lagene controllers, services og repositories, noe som gjør utviklingsprosessen mer organisert og enklere å vedlikeholde.

Hvert lag fokuserer på sin spesifikke oppgave, noe som forenkler både arbeidsflyt og prosjektstyring.

Alt var klart?

Hvordan kan vi forbedre det?

Takk for tilbakemeldingene dine!

Seksjon 2. Kapittel 5

Spør AI

expand

Spør AI

ChatGPT

Spør om hva du vil, eller prøv ett av de foreslåtte spørsmålene for å starte chatten vår

Suggested prompts:

Can you explain the main responsibilities of each layer in the three-tier architecture?

How does the data flow between the controller, service, and repository layers?

Why is it important to separate logic into different layers instead of using a single class?

Awesome!

Completion rate improved to 3.45

bookTrelagsarkitektur

Sveip for å vise menyen

Dette gjøres for å skille spesifikk logikk i ulike klasser/pakker, i stedet for å skrive alt i en enkelt klasse.

Rekkefølgen en forespørsel behandles i er ControllerServiceRepository. Deretter returneres responsen i motsatt rekkefølge: Repository -> Service -> Controller. Vi starter implementeringen med Repository-laget.

Repository-nivå

Dette er det laveste laget, hvor vi mottar prosessert data fra Service-laget og lagrer det i databasen.

Disse klassene er merket med @Repository-annotasjonen for å legges til i Spring-konteksten.

Main.java

Main.java

copy
1234
@Repository public class RepositoryLevel { // connect DB }

Eksempel på bruk av Repository

Servicenivå

Dette er hvor kjerne-logikken i applikasjonen utføres. I tjenester behandles eller endres data før det sendes videre til repository-laget.

For tjenester bruker vi @Service-annotasjonen, som deklarerer klassen som en service som inneholder forretningslogikken.

Main.java

Main.java

copy
1234567
@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }

Eksempel på bruk av tjeneste

Kontroller-nivå

Dette laget håndterer den innledende interaksjonen mellom klient og server. Alle forespørsler sendt fra klienten ankommer her, og det er ansvarlig for å motta data gitt av klienten.

Det behandler innkommende HTTP-forespørsler og returnerer HTTP-responser. Kontrollere fungerer som en "bro" mellom klienten og forretningslogikken.

På dette nivået brukes det to annotasjoner for å angi en klasse som en kontroller:

  • @RestController: Angir en klasse som en REST-kontroller, som håndterer HTTP-forespørsler og returnerer data i JSON-format;

  • @Controller: Angir en klasse som en MVC-kontroller, som håndterer forespørsler og returnerer visninger (f.eks. HTML).

Main.java

Main.java

copy
12345678
@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }

@GetMapping-annotasjonen angir URL-en for en gitt forespørsel. Dette betyr at vi legger til den spesifiserte stien /root til domenet, og til gjengjeld mottar vi den tilsvarende siden.

Eksempel på bruk av Controller

Thymeleaf-avhengigheten fra videoen

Her er lenken til Thymeleaf-avhengigheten i Maven-repositoriet.

Men hva skjer hvis du ikke følger denne tilnærmingen?

Teknisk sett, ingenting. Selv om du skriver all forretningslogikk i controlleren, kobler til databasen der, og returnerer responsen til klienten fra samme sted, vil alt fungere på samme måte.

Likevel vil du sannsynligvis ikke huske hva du skrev der etter noen uker, fordi all applikasjonslogikk vil være på ett sted, noe som er svært upraktisk.

Sammendrag

Trelagsarkitektur gir en tydelig separasjon av ansvar mellom lagene controllers, services og repositories, noe som gjør utviklingsprosessen mer organisert og enklere å vedlikeholde.

Hvert lag fokuserer på sin spesifikke oppgave, noe som forenkler både arbeidsflyt og prosjektstyring.

Alt var klart?

Hvordan kan vi forbedre det?

Takk for tilbakemeldingene dine!

Seksjon 2. Kapittel 5
some-alt