Trelagsarkitektur
Dette gøres for at adskille specifik logik i forskellige klasser/pakker i stedet for at skrive alt i en enkelt klasse.
Den rækkefølge, en forespørgsel behandles i, er Controller → Service → Repository. Herefter returneres svaret i omvendt rækkefølge: Repository -> Service -> Controller. Vi starter implementeringen med Repository-laget.
Repository-niveau
Dette er det laveste lag, hvor vi modtager behandlede data fra Service-laget og gemmer dem i vores database.
Disse klasser er markeret med @Repository-annotationen for at blive tilføjet til Spring-konteksten.
Main.java
1234@Repository public class RepositoryLevel { // connect DB }
Eksempel på brug af Repository
Serviceniveau
Her foregår kerne-logikken i applikationen. I services håndterer eller modificerer vi data, før vi sender det videre til repository-laget.
For services anvender vi @Service annotationen, som deklarerer klassen som en service, der indeholder forretningslogikken.
Main.java
1234567@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }
Eksempel på brug af Service
Controller-niveau
Dette lag håndterer den indledende interaktion mellem klient og server. Alle forespørgsler sendt fra klienten ankommer her, og det er ansvarligt for at modtage de data, klienten leverer.
Det behandler indkommende HTTP-forespørgsler og returnerer HTTP-svar. Controllere fungerer som en "bro" mellem klienten og forretningslogikken.
På dette niveau anvendes der to annoteringer til at udpege en klasse som en controller:
-
@RestController: Deklarerer en klasse som en REST-controller, der håndterer HTTP-forespørgsler og returnerer data i JSON-format; -
@Controller: Deklarerer en klasse som en MVC-controller, der håndterer forespørgsler og returnerer views (f.eks. HTML).
Main.java
12345678@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }
@GetMapping annotationen angiver URL'en for en given forespørgsel. Dette betyder, at vi tilføjer den specificerede sti /root til domænet, og til gengæld modtager vi den tilsvarende side.
Eksempel på brug af Controller
Thymeleaf-afhængigheden fra videoen
Her er linket til Thymeleaf-afhængigheden i Maven repository.
Men hvad sker der, hvis du ikke følger denne tilgang?
Teknisk set sker der intet. Selv hvis du skriver al forretningslogik i controlleren, opretter forbindelse til databasen der og returnerer svaret til klienten fra samme sted, vil alt fungere på samme måde.
Dog vil du sandsynligvis ikke kunne huske, hvad du skrev der efter et par uger, fordi al applikationslogik vil være samlet ét sted, hvilket er utroligt upraktisk.
Resumé
Tre-lags arkitekturen giver en tydelig adskillelse af ansvar mellem lagene controllers, services og repositories, hvilket gør udviklingsprocessen mere organiseret og nemmere at vedligeholde.
Hvert lag fokuserer på sin specifikke opgave, hvilket forenkler både arbejdsgang og projektstyring.
Tak for dine kommentarer!
Spørg AI
Spørg AI
Spørg om hvad som helst eller prøv et af de foreslåede spørgsmål for at starte vores chat
Awesome!
Completion rate improved to 3.45Trelagsarkitektur
Stryg for at vise menuen
Dette gøres for at adskille specifik logik i forskellige klasser/pakker i stedet for at skrive alt i en enkelt klasse.
Den rækkefølge, en forespørgsel behandles i, er Controller → Service → Repository. Herefter returneres svaret i omvendt rækkefølge: Repository -> Service -> Controller. Vi starter implementeringen med Repository-laget.
Repository-niveau
Dette er det laveste lag, hvor vi modtager behandlede data fra Service-laget og gemmer dem i vores database.
Disse klasser er markeret med @Repository-annotationen for at blive tilføjet til Spring-konteksten.
Main.java
1234@Repository public class RepositoryLevel { // connect DB }
Eksempel på brug af Repository
Serviceniveau
Her foregår kerne-logikken i applikationen. I services håndterer eller modificerer vi data, før vi sender det videre til repository-laget.
For services anvender vi @Service annotationen, som deklarerer klassen som en service, der indeholder forretningslogikken.
Main.java
1234567@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }
Eksempel på brug af Service
Controller-niveau
Dette lag håndterer den indledende interaktion mellem klient og server. Alle forespørgsler sendt fra klienten ankommer her, og det er ansvarligt for at modtage de data, klienten leverer.
Det behandler indkommende HTTP-forespørgsler og returnerer HTTP-svar. Controllere fungerer som en "bro" mellem klienten og forretningslogikken.
På dette niveau anvendes der to annoteringer til at udpege en klasse som en controller:
-
@RestController: Deklarerer en klasse som en REST-controller, der håndterer HTTP-forespørgsler og returnerer data i JSON-format; -
@Controller: Deklarerer en klasse som en MVC-controller, der håndterer forespørgsler og returnerer views (f.eks. HTML).
Main.java
12345678@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }
@GetMapping annotationen angiver URL'en for en given forespørgsel. Dette betyder, at vi tilføjer den specificerede sti /root til domænet, og til gengæld modtager vi den tilsvarende side.
Eksempel på brug af Controller
Thymeleaf-afhængigheden fra videoen
Her er linket til Thymeleaf-afhængigheden i Maven repository.
Men hvad sker der, hvis du ikke følger denne tilgang?
Teknisk set sker der intet. Selv hvis du skriver al forretningslogik i controlleren, opretter forbindelse til databasen der og returnerer svaret til klienten fra samme sted, vil alt fungere på samme måde.
Dog vil du sandsynligvis ikke kunne huske, hvad du skrev der efter et par uger, fordi al applikationslogik vil være samlet ét sted, hvilket er utroligt upraktisk.
Resumé
Tre-lags arkitekturen giver en tydelig adskillelse af ansvar mellem lagene controllers, services og repositories, hvilket gør udviklingsprocessen mere organiseret og nemmere at vedligeholde.
Hvert lag fokuserer på sin specifikke opgave, hvilket forenkler både arbejdsgang og projektstyring.
Tak for dine kommentarer!
