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
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
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
@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
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?
Fantastisk!
Completion rate forbedret til 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
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
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
@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!
